iOS Custom URI Handlers / Deeplinks / Custom Schemes

Información Básica

Los esquemas de URL personalizados permiten que las aplicaciones se comuniquen utilizando un protocolo personalizado, como se detalla en la Apple Developer Documentation. Estos esquemas deben ser declarados por la aplicación, que luego maneja las URL entrantes siguiendo esos esquemas. Es crucial validar todos los parámetros de la URL y descartar cualquier URL malformada para prevenir ataques a través de este vector.

Se da un ejemplo donde la URI myapp://hostname?data=123876123 invoca una acción específica de la aplicación. Una vulnerabilidad señalada estaba en la aplicación Skype Mobile, que permitía acciones de llamada no permitidas a través del protocolo skype://. Los esquemas registrados se pueden encontrar en el Info.plist de la aplicación bajo CFBundleURLTypes. Las aplicaciones maliciosas pueden explotar esto volviendo a registrar URIs para interceptar información sensible.

Registro de Esquemas de Consulta de Aplicaciones

Desde iOS 9.0, para verificar si una aplicación está disponible, canOpenURL: requiere declarar esquemas de URL en el Info.plist bajo LSApplicationQueriesSchemes. Esto limita los esquemas que una aplicación puede consultar a 50, mejorando la privacidad al prevenir la enumeración de aplicaciones.

<key>LSApplicationQueriesSchemes</key>
<array>
<string>url_scheme1</string>
<string>url_scheme2</string>
</array>

Pruebas de Manejo y Validación de URL

Los desarrolladores deben inspeccionar métodos específicos en el código fuente para entender la construcción y validación de rutas de URL, como application:didFinishLaunchingWithOptions: y application:openURL:options:. Por ejemplo, Telegram emplea varios métodos para abrir URLs:

func application(_ application: UIApplication, open url: URL, sourceApplication: String?) -> Bool {
self.openUrl(url: url)
return true
}

func application(_ application: UIApplication, open url: URL, sourceApplication: String?,
annotation: Any) -> Bool {
self.openUrl(url: url)
return true
}

func application(_ app: UIApplication, open url: URL,
options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
self.openUrl(url: url)
return true
}

func application(_ application: UIApplication, handleOpen url: URL) -> Bool {
self.openUrl(url: url)
return true
}

Pruebas de Solicitudes de URL a Otras Aplicaciones

Métodos como openURL:options:completionHandler: son cruciales para abrir URLs e interactuar con otras aplicaciones. Identificar el uso de tales métodos en el código fuente de la aplicación es clave para entender las comunicaciones externas.

Pruebas de Métodos Obsoletos

Los métodos obsoletos que manejan la apertura de URLs, como application:handleOpenURL: y openURL:, deben ser identificados y revisados por sus implicaciones de seguridad.

Fuzzing de Esquemas de URL

El fuzzing de esquemas de URL puede identificar errores de corrupción de memoria. Herramientas como Frida pueden automatizar este proceso abriendo URLs con diferentes cargas útiles para monitorear fallos, ejemplificado por la manipulación de URLs en la aplicación iGoat-Swift:

$ frida -U SpringBoard -l ios-url-scheme-fuzzing.js
[iPhone::SpringBoard]-> fuzz("iGoat", "iGoat://?contactNumber={0}&message={0}")
Watching for crashes from iGoat...
No logs were moved.
Opened URL: iGoat://?contactNumber=0&message=0

Secuestro de esquemas de URL personalizados

Según esta publicación, las aplicaciones maliciosas podrían registrar esquemas personalizados de otras aplicaciones, luego la aplicación maliciosa puede abrir un navegador que tiene todas las cookies de la aplicación Safari con ASWebAuthenticationSession.

Con el navegador, la aplicación maliciosa puede cargar una página web controlada por el atacante y TCC pedirá al usuario móvil permisos para abrir esa aplicación. Luego, la página web maliciosa podría redirigir a una página de víctima, por ejemplo, un flujo de OAuth con el parámetro prompt=none. Si el usuario ya había iniciado sesión en el flujo de OAuth, el flujo de OAuth enviará el secreto de vuelta a la aplicación víctima utilizando el esquema personalizado de la aplicación víctima.
Sin embargo, debido a que la aplicación maliciosa también lo registró y porque el navegador utilizado está dentro de la aplicación maliciosa, el esquema personalizado será manejado en este caso por la aplicación maliciosa, que podrá robar el token de OAuth.

Referencias

• https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0075/
• https://evanconnelly.github.io/post/ios-oauth/