Deeplinks e IPC

Las apps móviles no son islas: se comunican con otras apps y con el sistema a través de mecanismos de IPC (Inter-Process Communication) y de deeplinks (enlaces que abren la app en una pantalla concreta). Si esos puntos de entrada no validan quién los invoca ni la entrada que reciben, se convierten en una superficie de ataque: otra app (o una web) puede invocar funciones internas, pasar datos maliciosos o saltarse controles de la interfaz.

Deeplinks: tipos

# Android
Custom scheme:  targetapp://pantalla?param=valor      (cualquier app puede invocarlo)
App Links:      https://target.com/...  (verificados por dominio, más seguros)
# iOS
URL Schemes:    targetapp://...          (como custom scheme, no verificado)
Universal Links: https://target.com/...  (verificados por dominio)

Los esquemas custom (targetapp://) no están verificados: cualquier app o web puede invocarlos, así que lo que la app haga con ellos debe validarse.

Enumerar deeplinks

# Android: del manifest descompilado
# buscar <intent-filter> con <data android:scheme="..."> y android:host
apktool d app.apk ; grep -A5 'intent-filter' AndroidManifest.xml
# iOS: del Info.plist
plutil -p Info.plist | grep -A5 CFBundleURLSchemes

Probar deeplinks

# Android: invocar un deeplink
adb shell am start -W -a android.intent.action.VIEW -d "targetapp://admin?debug=1" com.target
# iOS: con el simulador o Frida
# abrir la URL y observar a qué pantalla/acción lleva y qué parámetros acepta

Vectores de ataque

# acceso no autorizado a pantallas/funciones internas
targetapp://admin  o  targetapp://transfer?to=atacante&amount=1000   (saltar la UI/checks)
# inyección a través de parámetros del deeplink
#   -> XSS si el parámetro llega a una WebView
#   -> SQLi / path traversal si llega a una query/fichero
#   -> open redirect / carga de URL controlada en WebView
# robo de datos: deeplink que hace a la app enviar datos a un destino controlado
# deeplinks que inician flujos sensibles sin re-autenticación

Componentes IPC (Android)

Más allá de deeplinks, los componentes exportados son IPC:

# Activities, Services, Broadcast Receivers, Content Providers con exported=true
adb shell am start -n com.target/.SecretActivity          # Activity
adb shell am startservice -n com.target/.AdminService     # Service
adb shell am broadcast -a com.target.ACTION_X             # Broadcast
adb shell content query --uri content://com.target.provider/data   # Content Provider
# drozer automatiza el análisis de toda esta superficie
drozer console connect ; run app.package.attacksurface com.target

Un Content Provider exportado sin permisos puede filtrar datos o ser vulnerable a SQLi/path traversal; un Receiver puede disparar lógica con intents falsos.

iOS: IPC y pasteboard

# URL schemes (arriba), extensiones de app, app groups compartidos
# pasteboard general (datos compartidos entre apps)
# Universal Links mal validados

Para la defensa

Validar la entrada de deeplinks/intents (parámetros, destinos) como cualquier input no confiable.
Preferir App Links/Universal Links (verificados por dominio) sobre esquemas custom.
Minimizar componentes exportados; proteger los necesarios con permisos; exported=false por defecto.
No ejecutar acciones sensibles desde un deeplink sin re-autenticación/confirmación.
WebViews seguras si un parámetro llega a ellas (sin JS innecesario, sin cargar URLs controladas).
Validar el origen (getCallingPackage/referrer) cuando importe quién invoca.

Checklist de prueba

Enumerar deeplinks (manifest / Info.plist)
Invocar deeplinks y ver a qué pantallas/acciones llevan
Acceso no autorizado a funciones internas vía deeplink
Inyección por parámetros (XSS en WebView, SQLi, traversal)
Componentes exportados Android (am/content, drozer)
Content Providers: SQLi/path traversal/fuga de datos
Flujos sensibles sin re-autenticación
iOS: URL schemes, Universal Links, pasteboard