# iOS Universal Links {{#include ../../banners/hacktricks-training.md}} ## Introduction Les liens universels offrent une **expérience de redirection fluide** aux utilisateurs en ouvrant directement le contenu dans l'application, contournant ainsi la nécessité d'une redirection Safari. Ces liens sont **uniques** et sécurisés, car ils ne peuvent pas être revendiqués par d'autres applications. Cela est assuré par l'hébergement d'un fichier JSON `apple-app-site-association` dans le répertoire racine du site web, établissant un lien vérifiable entre le site web et l'application. Dans les cas où l'application n'est pas installée, Safari prendra le relais et dirigera l'utilisateur vers la page web, maintenant ainsi la présence de l'application. Pour les testeurs de pénétration, le fichier `apple-app-site-association` est d'un intérêt particulier car il peut révéler des **chemins sensibles**, pouvant inclure ceux liés à des fonctionnalités non publiées. ### **Analyzing the Associated Domains Entitlement** Les développeurs activent les liens universels en configurant les **Domaines Associés** dans l'onglet Capacités de Xcode ou en inspectant le fichier `.entitlements`. Chaque domaine est préfixé par `applinks:`. Par exemple, la configuration de Telegram pourrait apparaître comme suit : ```xml com.apple.developer.associated-domains applinks:telegram.me applinks:t.me ``` Pour des informations plus complètes, référez-vous à la [documentation Apple Developer archivée](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html#//apple_ref/doc/uid/TP40016308-CH12-SW2). Si vous travaillez avec une application compilée, les autorisations peuvent être extraites comme indiqué dans [ce guide](extracting-entitlements-from-compiled-application.md). ### **Récupération du fichier Apple App Site Association** Le fichier `apple-app-site-association` doit être récupéré depuis le serveur en utilisant les domaines spécifiés dans les autorisations. Assurez-vous que le fichier est accessible via HTTPS directement à `https:///apple-app-site-association` (ou `/.well-known/apple-app-site-association`). Des outils comme le [validateur Apple App Site Association (AASA)](https://branch.io/resources/aasa-validator/) peuvent aider dans ce processus. > **Énumération rapide depuis un shell macOS/Linux** > > ```bash > # en supposant que vous avez extrait les autorisations dans ent.xml > doms=$(plutil -extract com.apple.developer.associated-domains xml1 -o - ent.xml | \ > grep -oE 'applinks:[^<]+' | cut -d':' -f2) > for d in $doms; do > echo "[+] Récupération de l'AASA pour $d"; > curl -sk "https://$d/.well-known/apple-app-site-association" | jq '.' > done > ``` ### **Gestion des liens universels dans l'application** L'application doit implémenter des méthodes spécifiques pour gérer correctement les liens universels. La méthode principale à rechercher est [`application:continueUserActivity:restorationHandler:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623072-application). Il est crucial que le schéma des URL gérées soit HTTP ou HTTPS, car d'autres ne seront pas prises en charge. #### **Validation de la méthode de gestion des données** Lorsqu'un lien universel ouvre une application, un objet `NSUserActivity` est passé à l'application avec l'URL. Avant de traiter cette URL, il est essentiel de la valider et de la nettoyer pour éviter les risques de sécurité. Voici un exemple en Swift qui démontre le processus : ```swift func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool { // Check for web browsing activity and valid URL if userActivity.activityType == NSUserActivityTypeBrowsingWeb, let url = userActivity.webpageURL { application.open(url, options: [:], completionHandler: nil) } return true } ``` Les URL doivent être soigneusement analysées et validées, surtout si elles incluent des paramètres, pour se protéger contre un éventuel spoofing ou des données malformées. L'API `NSURLComponents` est utile à cet effet, comme démontré ci-dessous : ```swift func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool { guard userActivity.activityType == NSUserActivityTypeBrowsingWeb, let incomingURL = userActivity.webpageURL, let components = NSURLComponents(url: incomingURL, resolvingAgainstBaseURL: true), let path = components.path, let params = components.queryItems else { return false } if let albumName = params.first(where: { $0.name == "albumname" })?.value, let photoIndex = params.first(where: { $0.name == "index" })?.value { // Process the URL with album name and photo index return true } else { // Handle invalid or missing parameters return false } } ``` À travers une **configuration et validation diligentes**, les développeurs peuvent s'assurer que les liens universels améliorent l'expérience utilisateur tout en maintenant des normes de sécurité et de confidentialité. ## Vulnérabilités courantes et vérifications de pentesting | # | Faiblesse | Comment tester | Exploitation / Impact | |---|----------|------------|-----------------------| | 1 | **`paths` / `components` trop larges** dans le fichier AASA (par exemple, `"/": "*"` ou des jokers tels que `"/a/*"`). | • Inspectez le AASA téléchargé et recherchez `*`, des barres obliques finales ou des règles `{"?": …}`.
• Essayez de demander des ressources inconnues qui correspondent toujours à la règle (`https://domain.com/a/evil?_p_dp=1`). | Détournement de lien universel : une application iOS malveillante qui enregistre le même domaine pourrait revendiquer tous ces liens et présenter une interface de phishing. Un exemple réel est le rapport de bug-bounty de Temu.com de mai 2025 où un attaquant pouvait rediriger n'importe quel chemin `/a/*` vers sa propre application. | | 2 | **Validation côté serveur manquante** des chemins de deep-link. | Après avoir identifié les chemins autorisés, émettez des requêtes `curl`/Burp vers des ressources non existantes et observez les codes d'état HTTP. Tout autre chose que `404` (par exemple, 200/302) est suspect. | Un attaquant peut héberger du contenu arbitraire derrière un chemin autorisé et le servir via le domaine légitime, augmentant le taux de réussite du phishing ou du vol de jetons de session. | | 3 | **Gestion des URL côté application sans liste blanche de schéma/hôte** (CVE-2024-10474 – Mozilla Focus < 132). | Recherchez des appels directs `openURL:`/`open(_:options:)` ou des ponts JavaScript qui transmettent des URL arbitraires. | Les pages internes peuvent faire passer des URL `myapp://` ou `https://` qui contournent les vérifications de sécurité de la barre d'URL du navigateur, entraînant des usurpations ou des actions privilégiées non intentionnelles. | | 4 | **Utilisation de sous-domaines génériques** (`*.example.com`) dans l'autorisation. | `grep` pour `*.` dans les autorisations. | Si un sous-domaine est pris (par exemple via un bucket S3 inutilisé), l'attaquant obtient automatiquement le lien universel. | ### Liste de vérification rapide * [ ] Extraire les autorisations et énumérer chaque entrée `applinks:`. * [ ] Télécharger AASA pour chaque entrée et auditer les jokers. * [ ] Vérifier que le serveur web renvoie **404** pour les chemins non définis. * [ ] Dans le binaire, confirmer que **seuls** les hôtes/schémas de confiance sont gérés. * [ ] Si l'application utilise la nouvelle syntaxe `components` (iOS 11+), tester les règles de paramètres de requête (`{"?":{…}}`). ## Outils - [GetUniversal.link](https://getuniversal.link/): Aide à simplifier le test et la gestion des liens universels de votre application et du fichier AASA. Il suffit d'entrer votre domaine pour vérifier l'intégrité du fichier AASA ou d'utiliser le tableau de bord personnalisé pour tester facilement le comportement des liens. Cet outil vous aide également à déterminer quand Apple indexera à nouveau votre fichier AASA. - [Knil](https://github.com/ethanhuang13/knil): Utilitaire iOS open-source qui récupère, analyse et vous permet de **tester** chaque lien universel déclaré par un domaine directement sur l'appareil. - [universal-link-validator](https://github.com/urbangems/universal-link-validator): Validateur CLI / web qui effectue des vérifications strictes de conformité AASA et met en évidence les jokers dangereux. ## Références - [https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0070/#static-analysis](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0070/#static-analysis) - [https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction#testing-object-persistence-mstg-platform-8](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction#testing-object-persistence-mstg-platform-8) - [https://medium.com/@m.habibgpi/universal-link-hijacking-via-misconfigured-aasa-file-on-temu-com-eadfcb745e4e](https://medium.com/@m.habibgpi/universal-link-hijacking-via-misconfigured-aasa-file-on-temu-com-eadfcb745e4e) - [https://nvd.nist.gov/vuln/detail/CVE-2024-10474](https://nvd.nist.gov/vuln/detail/CVE-2024-10474) {{#include ../../banners/hacktricks-training.md}}