iOS Custom URI Handlers / Deeplinks / Custom Schemes

Reading time: 5 minutes

Informations de base

Les schémas d'URL personnalisés permettent aux applications de communiquer en utilisant un protocole personnalisé, comme détaillé dans la documentation des développeurs Apple. Ces schémas doivent être déclarés par l'application, qui gère ensuite les URL entrantes suivant ces schémas. Il est crucial de valider tous les paramètres d'URL et d'écarter toute URL malformée pour prévenir les attaques via ce vecteur.

Un exemple est donné où l'URI myapp://hostname?data=123876123 invoque une action spécifique de l'application. Une vulnérabilité notée se trouvait dans l'application Skype Mobile, qui permettait des actions d'appel non autorisées via le protocole skype://. Les schémas enregistrés peuvent être trouvés dans le Info.plist de l'application sous CFBundleURLTypes. Les applications malveillantes peuvent exploiter cela en réenregistrant des URIs pour intercepter des informations sensibles.

Enregistrement des schémas de requête d'application

Depuis iOS 9.0, pour vérifier si une application est disponible, canOpenURL: nécessite de déclarer les schémas d'URL dans le Info.plist sous LSApplicationQueriesSchemes. Cela limite les schémas qu'une application peut interroger à 50, améliorant la confidentialité en empêchant l'énumération des applications.

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

Tester la gestion et la validation des URL

Les développeurs doivent inspecter des méthodes spécifiques dans le code source pour comprendre la construction et la validation des chemins d'URL, telles que application:didFinishLaunchingWithOptions: et application:openURL:options:. Par exemple, Telegram utilise diverses méthodes pour ouvrir des URL :

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
}

Tester les requêtes d'URL vers d'autres applications

Des méthodes comme openURL:options:completionHandler: sont cruciales pour ouvrir des URL afin d'interagir avec d'autres applications. Identifier l'utilisation de telles méthodes dans le code source de l'application est essentiel pour comprendre les communications externes.

Tester les méthodes obsolètes

Les méthodes obsolètes gérant l'ouverture d'URL, telles que application:handleOpenURL: et openURL:, doivent être identifiées et examinées pour leurs implications en matière de sécurité.

Fuzzing des schémas d'URL

Le fuzzing des schémas d'URL peut identifier des bugs de corruption de mémoire. Des outils comme Frida peuvent automatiser ce processus en ouvrant des URL avec des charges utiles variées pour surveiller les plantages, illustré par la manipulation des URL dans l'application 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

Détournement de schéma d'URL personnalisé

Selon ce post, des applications malveillantes pourraient enregistrer d'autres schémas personnalisés d'applications, puis l'application malveillante peut ouvrir un navigateur qui a tous les cookies de l'application Safari avec ASWebAuthenticationSession.

Avec le navigateur, l'application malveillante peut charger une page web contrôlée par un attaquant et TCC demandera à l'utilisateur mobile des autorisations pour ouvrir cette application. Ensuite, la page web malveillante pourrait rediriger vers une page victime, par exemple un flux OAuth avec le paramètre prompt=none. Si l'utilisateur était déjà connecté au flux OAuth, le flux OAuth renverra le secret à l'application victime en utilisant le schéma personnalisé de l'application victime.
Cependant, parce que l'application malveillante l'a également enregistré et parce que le navigateur utilisé est à l'intérieur de l'application malveillante, le schéma personnalisé sera géré dans ce cas par l'application malveillante qui pourra voler le jeton OAuth.

Références

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