- Travaillez-vous dans une entreprise de **cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Les schémas d'URL personnalisés [permettent aux applications de communiquer via un protocole personnalisé](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple\_ref/doc/uid/TP40007072-CH6-SW1). Une application doit déclarer la prise en charge des schémas et gérer les URL entrantes qui utilisent ces schémas.
> Les schémas d'URL offrent un vecteur d'attaque potentiel dans votre application, alors assurez-vous de **valider tous les paramètres d'URL** et de **rejeter tout URL malformé**. De plus, limitez les **actions** disponibles à celles qui ne risquent pas les données de l'utilisateur.
Par exemple, l'URI : `myapp://hostname?data=123876123`**déclenchera** l'**application** mydata (celle qui a **enregistré** le schéma `mydata`) pour l'**action** liée à l'**hostname** `hostname` en envoyant le **paramètre**`data` avec la valeur `123876123`.
Un exemple vulnérable est le [bug dans l'application mobile Skype](http://www.dhanjani.com/blog/2010/11/insecure-handling-of-url-schemes-in-apples-ios.html), découvert en 2010 : l'application Skype a enregistré le gestionnaire de protocole `skype://`, ce qui a **permis à d'autres applications de déclencher des appels vers d'autres utilisateurs Skype et des numéros de téléphone**. Malheureusement, Skype n'a pas demandé la permission des utilisateurs avant de passer les appels, de sorte que n'importe quelle application pouvait appeler des numéros arbitraires sans la connaissance de l'utilisateur. Les attaquants ont exploité cette vulnérabilité en mettant en place un `<iframe src="skype://xxx?call"></iframe>` invisible (où `xxx` était remplacé par un numéro premium), de sorte que tout utilisateur Skype qui a visité involontairement un site Web malveillant a appelé le numéro premium.
Vous pouvez trouver les **schémas enregistrés par une application** dans le fichier **`Info.plist`** de l'application en recherchant **`CFBundleURLTypes`** (exemple de [iGoat-Swift](https://github.com/OWASP/iGoat-Swift)) :
Cependant, notez que les applications malveillantes peuvent réenregistrer des URI déjà enregistrées par d'autres applications. Ainsi, si vous envoyez des informations sensibles via des URI (myapp://hostname?password=123456), une application malveillante peut intercepter l'URI avec les informations sensibles.
De plus, l'entrée de ces URI doit être vérifiée et nettoyée, car elle peut provenir d'origines malveillantes cherchant à exploiter des failles telles que les injections SQL, XSS, CSRF, les traversées de chemin ou d'autres vulnérabilités possibles.
Les applications peuvent appeler [`canOpenURL:`](https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl?language=objc) pour vérifier que l'application cible est disponible. Cependant, comme cette méthode était utilisée par des applications malveillantes pour énumérer les applications installées, [à partir d'iOS 9.0, les schémas d'URL passés doivent également être déclarés](https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl?language=objc#discussion) en ajoutant la clé `LSApplicationQueriesSchemes` au fichier `Info.plist` de l'application et un tableau d'**au plus 50 schémas d'URL**.
`canOpenURL` renverra toujours `NO` pour les schémas non déclarés, que l'application appropriée soit installée ou non. Cependant, cette restriction ne s'applique qu'à `canOpenURL`.
Afin de déterminer comment un chemin d'URL est construit et validé, si vous avez le code source original, vous pouvez **rechercher les méthodes suivantes** :
* Méthode `application:didFinishLaunchingWithOptions:` ou `application:will-FinishLaunchingWithOptions:` : vérifiez comment la décision est prise et comment les informations sur l'URL sont récupérées.
* [`application:openURL:options:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623112-application?language=objc) : vérifiez comment la ressource est ouverte, c'est-à-dire comment les données sont analysées, vérifiez les [options](https://developer.apple.com/documentation/uikit/uiapplication/openurloptionskey), en particulier si l'accès par l'application appelante ([`sourceApplication`](https://developer.apple.com/documentation/uikit/uiapplication/openurloptionskey/1623128-sourceapplication)) doit être autorisé ou refusé. L'application peut également avoir besoin de l'autorisation de l'utilisateur lors de l'utilisation du schéma d'URL personnalisé.
La méthode [`openURL:options:completionHandler:`](https://developer.apple.com/documentation/uikit/uiapplication/1648685-openurl?language=objc) et la méthode [`openURL:`](https://developer.apple.com/documentation/uikit/uiapplication/1622961-openurl?language=objc) de `UIApplication` (dépréciée) sont responsables de l'**ouverture d'URLs** (c'est-à-dire pour envoyer des requêtes / faire des requêtes à d'autres applications) qui peuvent être locales à l'application actuelle ou qui doivent être fournies par une autre application. Si vous avez le code source original, vous pouvez rechercher directement les utilisations de ces méthodes.
De plus, si vous êtes intéressé à savoir si l'application interroge des services ou des applications spécifiques, et si l'application est bien connue, vous pouvez également rechercher des schémas d'URL courants en ligne et les inclure dans vos **greps (liste des schémas d'applications iOS)**.
* **Safari**: Pour tester rapidement un schéma d'URL, vous pouvez ouvrir les URL sur Safari et observer le comportement de l'application. Par exemple, si vous écrivez `tel://123456789`, Safari essaiera de commencer l'appel du numéro.
* **Notes App**: Appuyez longuement sur les liens que vous avez écrits pour tester les schémas d'URL personnalisés. N'oubliez pas de quitter le mode d'édition pour pouvoir les ouvrir. Notez que vous pouvez cliquer ou appuyer longuement sur des liens incluant des schémas d'URL personnalisés uniquement si l'application est installée, sinon ils ne seront pas mis en évidence en tant que _liens cliquables_.
* Démarrez IDB, connectez-vous à votre appareil et sélectionnez l'application cible. Vous pouvez trouver des détails dans la [documentation IDB](https://www.idbtool.com/documentation/setup.html).
* Allez à la section **URL Handlers**. Dans les **URL schemes**, cliquez sur **Refresh**, et sur la gauche, vous trouverez une liste de tous les schémas personnalisés définis dans l'application testée. Vous pouvez charger ces schémas en cliquant sur **Open**, sur le côté droit. En ouvrant simplement un schéma d'URI vide (par exemple, en ouvrant `myURLscheme://`), vous pouvez découvrir des fonctionnalités cachées (par exemple, une fenêtre de débogage) et contourner l'authentification locale.
Dans cet exemple de [Frida CodeShare](https://codeshare.frida.re/@dki/ios-url-scheme-fuzzing/), l'auteur utilise l'API non publique `LSApplicationWorkspace.openSensitiveURL:withOptions:` pour ouvrir les URL (à partir de l'application SpringBoard) :
> Notez que l'utilisation d'API non publiques n'est pas autorisée sur l'App Store, c'est pourquoi nous ne les testons même pas, mais nous sommes autorisés à les utiliser pour notre analyse dynamique.
Ce que nous avons appris ci-dessus peut maintenant être utilisé pour construire votre propre fuzzer dans le langage de votre choix, par exemple en Python, et appeler `openURL` en utilisant [RPC de Frida](https://www.frida.re/docs/javascript-api/#rpc). Ce fuzzer doit faire ce qui suit :
Faire cela avec Frida est assez facile, vous pouvez vous référer à ce [blog post](https://grepharder.github.io/blog/0x03\_learning\_about\_universal\_links\_and\_fuzzing\_url\_schemes\_on\_ios\_with\_frida.html) pour voir un exemple qui fuzzes l'application iGoat-Swift (fonctionnant sur iOS 11.1.2).
Avant d'exécuter le fuzzer, nous avons besoin des schémas d'URL en tant qu'entrées. À partir de l'analyse statique, nous savons que l'application iGoat-Swift prend en charge le schéma d'URL et les paramètres suivants : `iGoat://?contactNumber={0}&message={0}`.
- Travaillez-vous dans une entreprise de **cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
