mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
78 lines
5.4 KiB
Markdown
78 lines
5.4 KiB
Markdown
# iOS Custom URI Handlers / Deeplinks / Custom Schemes
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
## 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](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW1). 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.
|
|
```xml
|
|
<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 :
|
|
```swift
|
|
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](https://codeshare.frida.re/@dki/ios-url-scheme-fuzzing/) 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 :
|
|
```bash
|
|
$ 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**](https://evanconnelly.github.io/post/ios-oauth/), 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](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/2990952-init#parameters).
|
|
|
|
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://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0075/)
|
|
- [https://evanconnelly.github.io/post/ios-oauth/](https://evanconnelly.github.io/post/ios-oauth/)
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|