# Fundamentos de Aplicaciones Android
{% hint style="success" %}
Aprende y practica Hacking en AWS:
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Aprende y practica Hacking en GCP: 
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Apoya a HackTricks
* Revisa los [**planes de suscripci贸n**](https://github.com/sponsors/carlospolop)!
* **脷nete al** 馃挰 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **s铆guenos** en **Twitter** 馃惁 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos de github.
{% endhint %}
## Modelo de Seguridad de Android
**Hay dos capas:**
* El **SO**, que mantiene las aplicaciones instaladas aisladas entre s铆.
* La **aplicaci贸n en s铆**, que permite a los desarrolladores **exponer ciertas funcionalidades** y configura las capacidades de la aplicaci贸n.
### Separaci贸n de UID
**A cada aplicaci贸n se le asigna un ID de usuario espec铆fico**. Esto se hace durante la instalaci贸n de la aplicaci贸n para que **la aplicaci贸n solo pueda interactuar con archivos propiedad de su ID de usuario o archivos compartidos**. Por lo tanto, solo la propia aplicaci贸n, ciertos componentes del SO y el usuario root pueden acceder a los datos de la aplicaci贸n.
### Compartici贸n de UID
**Dos aplicaciones pueden configurarse para usar el mismo UID**. Esto puede ser 煤til para compartir informaci贸n, pero si una de ellas se ve comprometida, los datos de ambas aplicaciones se ver谩n comprometidos. Por eso se **desaconseja** este comportamiento.\
**Para compartir el mismo UID, las aplicaciones deben definir el mismo valor `android:sharedUserId` en sus manifiestos.**
### Sandbox
El **Sandbox de Aplicaciones Android** permite ejecutar **cada aplicaci贸n** como un **proceso separado bajo un ID de usuario separado**. Cada proceso tiene su propia m谩quina virtual, por lo que el c贸digo de una aplicaci贸n se ejecuta en aislamiento de otras aplicaciones.\
Desde Android 5.0(L), se aplica **SELinux**. B谩sicamente, SELinux deniega todas las interacciones de procesos y luego crea pol铆ticas para **permitir solo las interacciones esperadas entre ellos**.
### Permisos
Cuando instalas una **aplicaci贸n y solicita permisos**, la aplicaci贸n est谩 pidiendo los permisos configurados en los elementos **`uses-permission`** en el archivo **AndroidManifest.xml**. El elemento **uses-permission** indica el nombre del permiso solicitado dentro del **atributo name**. Tambi茅n tiene el atributo **maxSdkVersion** que detiene la solicitud de permisos en versiones superiores a la especificada.\
Ten en cuenta que las aplicaciones de Android no necesitan pedir todos los permisos al principio, tambi茅n pueden **solicitar permisos din谩micamente**, pero todos los permisos deben ser **declarados** en el **manifiesto**.
Cuando una aplicaci贸n expone funcionalidad, puede limitar el **acceso solo a aplicaciones que tengan un permiso espec铆fico**.\
Un elemento de permiso tiene tres atributos:
* El **nombre** del permiso
* El atributo **permission-group**, que permite agrupar permisos relacionados.
* El **nivel de protecci贸n** que indica c贸mo se otorgan los permisos. Hay cuatro tipos:
* **Normal**: Se utiliza cuando **no hay amenazas conocidas** para la aplicaci贸n. No se **requiere la aprobaci贸n del usuario**.
* **Peligroso**: Indica que el permiso otorga a la aplicaci贸n solicitante un **acceso elevado**. **Se solicita la aprobaci贸n de los usuarios**.
* **Firma**: Solo **las aplicaciones firmadas por el mismo certificado que el que** exporta el componente pueden recibir permiso. Este es el tipo de protecci贸n m谩s fuerte.
* **FirmaOSistema**: Solo **las aplicaciones firmadas por el mismo certificado que el que** exporta el componente o **las aplicaciones que se ejecutan con acceso a nivel de sistema** pueden recibir permisos.
## Aplicaciones Preinstaladas
Estas aplicaciones generalmente se encuentran en los directorios **`/system/app`** o **`/system/priv-app`** y algunas de ellas est谩n **optimizadas** (puede que ni siquiera encuentres el archivo `classes.dex`). Estas aplicaciones valen la pena revisarlas porque a veces est谩n **ejecut谩ndose con demasiados permisos** (como root).
* Las que se env铆an con el **AOSP** (Android OpenSource Project) **ROM**
* Agregadas por el **fabricante** del dispositivo
* Agregadas por el **proveedor de telefon铆a m贸vil** (si se compr贸 a ellos)
## Rooting
Para obtener acceso root en un dispositivo Android f铆sico, generalmente necesitas **explotar** 1 o 2 **vulnerabilidades** que suelen ser **espec铆ficas** para el **dispositivo** y **versi贸n**.\
Una vez que la explotaci贸n ha funcionado, generalmente se copia el binario de Linux `su` en una ubicaci贸n especificada en la variable de entorno PATH del usuario, como `/system/xbin`.
Una vez que el binario de su est谩 configurado, se utiliza otra aplicaci贸n de Android para interactuar con el binario `su` y **procesar solicitudes de acceso root** como **Superuser** y **SuperSU** (disponible en Google Play Store).
{% hint style="danger" %}
Ten en cuenta que el proceso de rooting es muy peligroso y puede da帽ar severamente el dispositivo.
{% endhint %}
### ROMs
Es posible **reemplazar el SO instalando un firmware personalizado**. Haciendo esto, es posible extender la utilidad de un dispositivo antiguo, eludir restricciones de software o acceder al 煤ltimo c贸digo de Android.\
**OmniROM** y **LineageOS** son dos de los firmwares m谩s populares para usar.
Ten en cuenta que **no siempre es necesario rootear el dispositivo** para instalar un firmware personalizado. **Algunos fabricantes permiten** el desbloqueo de sus bootloaders de manera bien documentada y segura.
### Implicaciones
Una vez que un dispositivo est谩 rooteado, cualquier aplicaci贸n podr铆a solicitar acceso como root. Si una aplicaci贸n maliciosa lo obtiene, tendr谩 acceso a casi todo y podr谩 da帽ar el tel茅fono.
## Fundamentos de Aplicaciones Android
- El formato de las aplicaciones Android se conoce como _formato de archivo APK_. Es esencialmente un **archivo ZIP** (cambiando la extensi贸n del archivo a .zip, se pueden extraer y ver los contenidos).
- Contenidos de APK (No exhaustivo)
- **AndroidManifest.xml**
- resources.arsc/strings.xml
- resources.arsc: contiene recursos precompilados, como XML binario.
- res/xml/files\_paths.xml
- META-INF/
- 隆Aqu铆 es donde se encuentra el Certificado!
- **classes.dex**
- Contiene bytecode Dalvik, que representa el c贸digo Java (o Kotlin) compilado que la aplicaci贸n ejecuta por defecto.
- lib/
- Alberga bibliotecas nativas, segregadas por arquitectura de CPU en subdirectorios.
- `armeabi`: c贸digo para procesadores basados en ARM
- `armeabi-v7a`: c贸digo para procesadores ARMv7 y superiores
- `x86`: c贸digo para procesadores X86
- `mips`: c贸digo solo para procesadores MIPS
- assets/
- Almacena archivos diversos necesarios para la aplicaci贸n, que pueden incluir bibliotecas nativas adicionales o archivos DEX, a veces utilizados por autores de malware para ocultar c贸digo adicional.
- res/
- Contiene recursos que no est谩n compilados en resources.arsc
### **Dalvik y Smali**
En el desarrollo de Android, se utiliza **Java o Kotlin** para crear aplicaciones. En lugar de usar la JVM como en las aplicaciones de escritorio, Android compila este c贸digo en **bytecode ejecutable Dalvik (DEX)**. Anteriormente, la m谩quina virtual Dalvik manejaba este bytecode, pero ahora, el Android Runtime (ART) se encarga en las versiones m谩s nuevas de Android.
Para la ingenier铆a inversa, **Smali** se vuelve crucial. Es la versi贸n legible por humanos del bytecode DEX, actuando como un lenguaje ensamblador al traducir el c贸digo fuente en instrucciones de bytecode. Smali y baksmali se refieren a las herramientas de ensamblaje y desensamblaje en este contexto.
## Intenciones
Las intenciones son el medio principal por el cual las aplicaciones Android se comunican entre sus componentes o con otras aplicaciones. Estos objetos de mensaje tambi茅n pueden transportar datos entre aplicaciones o componentes, similar a c贸mo se utilizan las solicitudes GET/POST en las comunicaciones HTTP.
As铆 que una Intenci贸n es b谩sicamente un **mensaje que se pasa entre componentes**. Las Intenciones **pueden dirigirse** a componentes o aplicaciones espec铆ficas, **o pueden enviarse sin un destinatario espec铆fico**.\
Para ser simple, la Intenci贸n se puede usar:
* Para iniciar una Actividad, t铆picamente abriendo una interfaz de usuario para una aplicaci贸n
* Como transmisiones para informar al sistema y a las aplicaciones sobre cambios
* Para iniciar, detener y comunicarse con un servicio en segundo plano
* Para acceder a datos a trav茅s de ContentProviders
* Como callbacks para manejar eventos
Si es vulnerable, **las Intenciones pueden ser utilizadas para realizar una variedad de ataques**.
### Filtro de Intenci贸n
**Los Filtros de Intenci贸n** definen **c贸mo una actividad, servicio o Receptor de Transmisi贸n puede interactuar con diferentes tipos de Intenciones**. Esencialmente, describen las capacidades de estos componentes, como qu茅 acciones pueden realizar o los tipos de transmisiones que pueden procesar. El lugar principal para declarar estos filtros es dentro del **archivo AndroidManifest.xml**, aunque para los Receptores de Transmisi贸n, tambi茅n es una opci贸n codificarlos.
Los Filtros de Intenci贸n se componen de categor铆as, acciones y filtros de datos, con la posibilidad de incluir metadatos adicionales. Esta configuraci贸n permite que los componentes manejen Intenciones espec铆ficas que coincidan con los criterios declarados.
Un aspecto cr铆tico de los componentes de Android (actividades/servicios/proveedores de contenido/receptores de transmisi贸n) es su visibilidad o **estado p煤blico**. Un componente se considera p煤blico y puede interactuar con otras aplicaciones si est谩 **`exportado`** con un valor de **`true`** o si se declara un Filtro de Intenci贸n para 茅l en el manifiesto. Sin embargo, hay una manera para que los desarrolladores mantengan expl铆citamente estos componentes privados, asegurando que no interact煤en con otras aplicaciones de manera no intencionada. Esto se logra configurando el atributo **`exported`** en **`false`** en sus definiciones de manifiesto.
Adem谩s, los desarrolladores tienen la opci贸n de asegurar a煤n m谩s el acceso a estos componentes al requerir permisos espec铆ficos. El atributo **`permission`** se puede establecer para hacer cumplir que solo las aplicaciones con el permiso designado puedan acceder al componente, a帽adiendo una capa adicional de seguridad y control sobre qui茅n puede interactuar con 茅l.
```java
```
### Intenciones Impl铆citas
Las intenciones se crean program谩ticamente utilizando un constructor de Intenci贸n:
```java
Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
```
La **Acci贸n** de la intenci贸n declarada previamente es **ACTION\_SEND** y el **Extra** es un mailto **Uri** (el Extra es la informaci贸n adicional que la intenci贸n est谩 esperando).
Esta intenci贸n debe ser declarada dentro del manifiesto como en el siguiente ejemplo:
```xml
```
Un intent-filter necesita coincidir con la **acci贸n**, **datos** y **categor铆a** para recibir un mensaje.
El proceso de "resoluci贸n de Intent" determina qu茅 aplicaci贸n debe recibir cada mensaje. Este proceso considera el **atributo de prioridad**, que se puede establecer en la **declaraci贸n de intent-filter**, y **el que tenga la mayor prioridad ser谩 seleccionado**. Esta prioridad se puede establecer entre -1000 y 1000 y las aplicaciones pueden usar el valor `SYSTEM_HIGH_PRIORITY`. Si surge un **conflicto**, aparece una ventana de "elecci贸n" para que el **usuario pueda decidir**.
### Intents Expl铆citos
Un intent expl铆cito especifica el nombre de la clase a la que est谩 dirigido:
```java
Intent downloadIntent = new (this, DownloadService.class):
```
En otras aplicaciones, para acceder a la intenci贸n previamente declarada, puedes usar:
```java
Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);
```
### Pending Intents
Estos permiten que otras aplicaciones **realicen acciones en nombre de su aplicaci贸n**, utilizando la identidad y los permisos de su app. Al construir un Pending Intent, se debe **especificar un intent y la acci贸n a realizar**. Si el **intent declarado no es expl铆cito** (no declara qu茅 intent puede llamarlo), una **aplicaci贸n maliciosa podr铆a realizar la acci贸n declarada** en nombre de la app v铆ctima. Adem谩s, **si no se especifica una acci贸n**, la app maliciosa podr谩 hacer **cualquier acci贸n en nombre de la v铆ctima**.
### Broadcast Intents
A diferencia de los intents anteriores, que solo son recibidos por una app, los broadcast intents **pueden ser recibidos por m煤ltiples apps**. Sin embargo, desde la versi贸n de API 14, es **posible especificar la app que deber铆a recibir** el mensaje usando Intent.setPackage.
Alternativamente, tambi茅n es posible **especificar un permiso al enviar el broadcast**. La app receptora necesitar谩 tener ese permiso.
Hay **dos tipos** de Broadcasts: **Normal** (as铆ncrono) y **Ordenado** (s铆ncrono). El **orden** se basa en la **prioridad configurada dentro del elemento receptor**. **Cada app puede procesar, retransmitir o descartar el Broadcast.**
Es posible **enviar** un **broadcast** usando la funci贸n `sendBroadcast(intent, receiverPermission)` de la clase `Context`.\ Tambi茅n podr铆a usar la funci贸n **`sendBroadcast`** de **`LocalBroadCastManager`** que asegura que el **mensaje nunca salga de la app**. Usando esto, ni siquiera necesitar谩 exportar un componente receptor.
### Sticky Broadcasts
Este tipo de Broadcasts **pueden ser accedidos mucho despu茅s de haber sido enviados**.\
Estos fueron desaprobados en el nivel de API 21 y se recomienda **no usarlos**.\
**Permiten que cualquier aplicaci贸n intercepte los datos, pero tambi茅n los modifique.**
Si encuentra funciones que contengan la palabra "sticky" como **`sendStickyBroadcast`** o **`sendStickyBroadcastAsUser`**, **verifique el impacto y trate de eliminarlas**.
## Deep links / URL schemes
En las aplicaciones de Android, **deep links** se utilizan para iniciar una acci贸n (Intent) directamente a trav茅s de una URL. Esto se hace declarando un **esquema de URL** espec铆fico dentro de una actividad. Cuando un dispositivo Android intenta **acceder a una URL con este esquema**, se lanza la actividad especificada dentro de la aplicaci贸n.
El esquema debe ser declarado en el **`AndroidManifest.xml`**:
```xml
[...]
[...]
```
El esquema del ejemplo anterior es `exampleapp://` (nota tambi茅n el **`category BROWSABLE`**)
Luego, en el campo de datos, puedes especificar el **host** y **path**:
```xml
```
Para acceder a ello desde la web, es posible establecer un enlace como:
```xml
click here
click here
```
Para encontrar el **c贸digo que se ejecutar谩 en la App**, ve a la actividad llamada por el deeplink y busca la funci贸n **`onNewIntent`**.
Aprende a [llamar enlaces profundos sin usar p谩ginas HTML](./#exploiting-schemes-deep-links).
## AIDL - Lenguaje de Definici贸n de Interfaces de Android
El **Lenguaje de Definici贸n de Interfaces de Android (AIDL)** est谩 dise帽ado para facilitar la comunicaci贸n entre cliente y servicio en aplicaciones de Android a trav茅s de **comunicaci贸n entre procesos** (IPC). Dado que no se permite acceder directamente a la memoria de otro proceso en Android, AIDL simplifica el proceso al marshalling de objetos en un formato entendido por el sistema operativo, facilitando as铆 la comunicaci贸n entre diferentes procesos.
### Conceptos Clave
- **Servicios Vinculados**: Estos servicios utilizan AIDL para IPC, permitiendo que actividades o componentes se vinculen a un servicio, realicen solicitudes y reciban respuestas. El m茅todo `onBind` en la clase del servicio es cr铆tico para iniciar la interacci贸n, marc谩ndolo como un 谩rea vital para la revisi贸n de seguridad en busca de vulnerabilidades.
- **Messenger**: Operando como un servicio vinculado, Messenger facilita IPC con un enfoque en el procesamiento de datos a trav茅s del m茅todo `onBind`. Es esencial inspeccionar este m茅todo de cerca en busca de cualquier manejo de datos inseguro o ejecuci贸n de funciones sensibles.
- **Binder**: Aunque el uso directo de la clase Binder es menos com煤n debido a la abstracci贸n de AIDL, es beneficioso entender que Binder act煤a como un controlador a nivel de n煤cleo que facilita la transferencia de datos entre los espacios de memoria de diferentes procesos. Para una comprensi贸n m谩s profunda, hay un recurso disponible en [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8).
## Componentes
Estos incluyen: **Actividades, Servicios, Receptores de Difusi贸n y Proveedores.**
### Actividad de Lanzamiento y otras actividades
En las aplicaciones de Android, **las actividades** son como pantallas, mostrando diferentes partes de la interfaz de usuario de la app. Una app puede tener muchas actividades, cada una presentando una pantalla 煤nica al usuario.
La **actividad de lanzamiento** es la puerta principal a una app, lanzada cuando tocas el 铆cono de la app. Est谩 definida en el archivo de manifiesto de la app con intenciones espec铆ficas MAIN y LAUNCHER:
```markup
```
No todas las aplicaciones necesitan una actividad de lanzamiento, especialmente aquellas sin una interfaz de usuario, como los servicios en segundo plano.
Las actividades pueden estar disponibles para otras aplicaciones o procesos marc谩ndolas como "exportadas" en el manifiesto. Esta configuraci贸n permite que otras aplicaciones inicien esta actividad:
```markdown
```
Sin embargo, acceder a una actividad de otra aplicaci贸n no siempre representa un riesgo de seguridad. La preocupaci贸n surge si se comparten datos sensibles de manera inapropiada, lo que podr铆a llevar a filtraciones de informaci贸n.
El ciclo de vida de una actividad **comienza con el m茅todo onCreate**, configurando la interfaz de usuario y preparando la actividad para la interacci贸n con el usuario.
### Subclase de Aplicaci贸n
En el desarrollo de Android, una aplicaci贸n tiene la opci贸n de crear una **subclase** de la clase [Application](https://developer.android.com/reference/android/app/Application), aunque no es obligatorio. Cuando se define tal subclase, se convierte en la primera clase en ser instanciada dentro de la aplicaci贸n. El m茅todo **`attachBaseContext`**, si se implementa en esta subclase, se ejecuta antes del m茅todo **`onCreate`**. Esta configuraci贸n permite una inicializaci贸n temprana antes de que comience el resto de la aplicaci贸n.
```java
public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}
@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}
```
### Servicios
[Servicios](https://developer.android.com/guide/components/services) son **operativos en segundo plano** capaces de ejecutar tareas sin una interfaz de usuario. Estas tareas pueden continuar ejecut谩ndose incluso cuando los usuarios cambian a diferentes aplicaciones, lo que hace que los servicios sean cruciales para **operaciones de larga duraci贸n**.
Los servicios son vers谩tiles; pueden iniciarse de varias maneras, siendo **Intents** el m茅todo principal para lanzarlos como punto de entrada de una aplicaci贸n. Una vez que un servicio se inicia utilizando el m茅todo `startService`, su m茅todo `onStart` entra en acci贸n y sigue ejecut谩ndose hasta que se llama expl铆citamente al m茅todo `stopService`. Alternativamente, si el papel de un servicio depende de una conexi贸n de cliente activa, se utiliza el m茅todo `bindService` para vincular al cliente con el servicio, activando el m茅todo `onBind` para el paso de datos.
Una aplicaci贸n interesante de los servicios incluye la reproducci贸n de m煤sica en segundo plano o la obtenci贸n de datos de red sin obstaculizar la interacci贸n del usuario con una aplicaci贸n. Adem谩s, los servicios pueden hacerse accesibles a otros procesos en el mismo dispositivo a trav茅s de **exportaci贸n**. Este no es el comportamiento predeterminado y requiere una configuraci贸n expl铆cita en el archivo Android Manifest:
```xml
```
### Broadcast Receivers
**Broadcast receivers** act煤an como oyentes en un sistema de mensajer铆a, permitiendo que m煤ltiples aplicaciones respondan a los mismos mensajes del sistema. Una aplicaci贸n puede **registrar un receptor** de **dos maneras principales**: a trav茅s del **Manifest** de la aplicaci贸n o **din谩micamente** dentro del c贸digo de la aplicaci贸n mediante la API **`registerReceiver`**. En el Manifest, las transmisiones se filtran con permisos, mientras que los receptores registrados din谩micamente tambi茅n pueden especificar permisos al registrarse.
Los **filtros de intenci贸n** son cruciales en ambos m茅todos de registro, determinando qu茅 transmisiones activan el receptor. Una vez que se env铆a una transmisi贸n coincidente, se invoca el m茅todo **`onReceive`** del receptor, lo que permite que la aplicaci贸n reaccione en consecuencia, como ajustar el comportamiento en respuesta a una alerta de bater铆a baja.
Las transmisiones pueden ser **as铆ncronas**, alcanzando todos los receptores sin orden, o **sincr贸nicas**, donde los receptores reciben la transmisi贸n seg煤n las prioridades establecidas. Sin embargo, es importante tener en cuenta el riesgo de seguridad potencial, ya que cualquier aplicaci贸n puede priorizarse a s铆 misma para interceptar una transmisi贸n.
Para entender la funcionalidad de un receptor, busque el m茅todo **`onReceive`** dentro de su clase. El c贸digo de este m茅todo puede manipular la Intent recibida, destacando la necesidad de validaci贸n de datos por parte de los receptores, especialmente en **Broadcasts Ordenados**, que pueden modificar o eliminar la Intent.
### Content Provider
**Content Providers** son esenciales para **compartir datos estructurados** entre aplicaciones, enfatizando la importancia de implementar **permisos** para garantizar la seguridad de los datos. Permiten que las aplicaciones accedan a datos de diversas fuentes, incluidos bases de datos, sistemas de archivos o la web. Permisos espec铆ficos, como **`readPermission`** y **`writePermission`**, son cruciales para controlar el acceso. Adem谩s, se puede otorgar acceso temporal a trav茅s de configuraciones de **`grantUriPermission`** en el manifest de la aplicaci贸n, aprovechando atributos como `path`, `pathPrefix` y `pathPattern` para un control de acceso detallado.
La validaci贸n de entrada es primordial para prevenir vulnerabilidades, como la inyecci贸n SQL. Los Content Providers admiten operaciones b谩sicas: `insert()`, `update()`, `delete()`, y `query()`, facilitando la manipulaci贸n y el intercambio de datos entre aplicaciones.
**FileProvider**, un Content Provider especializado, se centra en compartir archivos de manera segura. Se define en el manifest de la aplicaci贸n con atributos espec铆ficos para controlar el acceso a carpetas, denotadas por `android:exported` y `android:resource` que apuntan a configuraciones de carpetas. Se aconseja precauci贸n al compartir directorios para evitar exponer datos sensibles inadvertidamente.
Ejemplo de declaraci贸n de manifest para FileProvider:
```xml
```
Y un ejemplo de especificar carpetas compartidas en `filepaths.xml`:
```xml
```
Para m谩s informaci贸n, consulta:
- [Android Developers: Content Providers](https://developer.android.com/guide/topics/providers/content-providers)
- [Android Developers: FileProvider](https://developer.android.com/training/secure-file-sharing/setup-sharing)
## WebViews
WebViews son como **mini navegadores web** dentro de aplicaciones Android, extrayendo contenido ya sea de la web o de archivos locales. Enfrentan riesgos similares a los de los navegadores regulares, sin embargo, hay formas de **reducir estos riesgos** a trav茅s de **configuraciones** espec铆ficas.
Android ofrece dos tipos principales de WebView:
- **WebViewClient** es excelente para HTML b谩sico pero no soporta la funci贸n de alerta de JavaScript, afectando c贸mo se pueden probar los ataques XSS.
- **WebChromeClient** act煤a m谩s como la experiencia completa del navegador Chrome.
Un punto clave es que los navegadores WebView **no comparten cookies** con el navegador principal del dispositivo.
Para cargar contenido, est谩n disponibles m茅todos como ````loadUrl````, ````loadData````, y ````loadDataWithBaseURL````. Es crucial asegurarse de que estas URLs o archivos sean **seguros para usar**. Las configuraciones de seguridad se pueden gestionar a trav茅s de la clase ````WebSettings````. Por ejemplo, deshabilitar JavaScript con ````setJavaScriptEnabled(false)```` puede prevenir ataques XSS.
El "Bridge" de JavaScript permite que los objetos Java interact煤en con JavaScript, requiriendo que los m茅todos est茅n marcados con ````@JavascriptInterface```` para seguridad desde Android 4.2 en adelante.
Permitir el acceso al contenido (````setAllowContentAccess(true)````) permite que los WebViews accedan a Content Providers, lo que podr铆a ser un riesgo a menos que las URLs de contenido sean verificadas como seguras.
Para controlar el acceso a archivos:
- Deshabilitar el acceso a archivos (````setAllowFileAccess(false)````) limita el acceso al sistema de archivos, con excepciones para ciertos activos, asegurando que solo se utilicen para contenido no sensible.
## Otros Componentes de la Aplicaci贸n y Gesti贸n de Dispositivos M贸viles
### **Firma Digital de Aplicaciones**
- La **firma digital** es imprescindible para las aplicaciones Android, asegurando que sean **aut茅nticamente creadas** antes de la instalaci贸n. Este proceso utiliza un certificado para la identificaci贸n de la aplicaci贸n y debe ser verificado por el administrador de paquetes del dispositivo al momento de la instalaci贸n. Las aplicaciones pueden ser **autofirmadas o certificadas por una CA externa**, protegiendo contra accesos no autorizados y asegurando que la aplicaci贸n permanezca sin alteraciones durante su entrega al dispositivo.
### **Verificaci贸n de Aplicaciones para Mayor Seguridad**
- A partir de **Android 4.2**, una funci贸n llamada **Verificar Aplicaciones** permite a los usuarios verificar la seguridad de las aplicaciones antes de la instalaci贸n. Este **proceso de verificaci贸n** puede advertir a los usuarios sobre aplicaciones potencialmente da帽inas, o incluso prevenir la instalaci贸n de aquellas particularmente maliciosas, mejorando la seguridad del usuario.
### **Gesti贸n de Dispositivos M贸viles (MDM)**
- Las **soluciones MDM** proporcionan **supervisi贸n y seguridad** para dispositivos m贸viles a trav茅s de la **API de Administraci贸n de Dispositivos**. Necesitan la instalaci贸n de una aplicaci贸n Android para gestionar y asegurar dispositivos m贸viles de manera efectiva. Las funciones clave incluyen **hacer cumplir pol铆ticas de contrase帽as**, **exigir cifrado de almacenamiento**, y **permitir el borrado remoto de datos**, asegurando un control y seguridad completos sobre los dispositivos m贸viles.
```java
// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);
if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}
```
{% hint style="success" %}
Aprende y practica Hacking en AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Aprende y practica Hacking en GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Apoya a HackTricks
* Revisa los [**planes de suscripci贸n**](https://github.com/sponsors/carlospolop)!
* **脷nete al** 馃挰 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **s铆guenos** en **Twitter** 馃惁 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
{% endhint %}