iOS Custom URI Handlers / Deeplinks / Custom Schemes

Reading time: 4 minutes

Grundinformationen

Benutzerdefinierte URL-Schemata ermöglichen es Apps, über ein benutzerdefiniertes Protokoll zu kommunizieren, wie in der Apple Developer Documentation beschrieben. Diese Schemata müssen von der App deklariert werden, die dann eingehende URLs gemäß diesen Schemata verarbeitet. Es ist entscheidend, alle URL-Parameter zu validieren und alle fehlerhaften URLs zu verwerfen, um Angriffe über diesen Vektor zu verhindern.

Ein Beispiel wird gegeben, bei dem die URI myapp://hostname?data=123876123 eine spezifische Anwendungsaktion auslöst. Eine festgestellte Schwachstelle war in der Skype Mobile-App, die unzulässige Anrufaktionen über das skype://-Protokoll ermöglichte. Die registrierten Schemata finden sich in der Info.plist der App unter CFBundleURLTypes. Bösartige Anwendungen können dies ausnutzen, indem sie URIs erneut registrieren, um sensible Informationen abzufangen.

Registrierung von Anwendungsabfrage-Schemata

Seit iOS 9.0 erfordert canOpenURL:, um zu überprüfen, ob eine App verfügbar ist, die Deklaration von URL-Schemata in der Info.plist unter LSApplicationQueriesSchemes. Dies begrenzt die Schemata, die eine App abfragen kann, auf 50 und verbessert die Privatsphäre, indem es die Aufzählung von Apps verhindert.

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

Testen der URL-Verarbeitung und -Validierung

Entwickler sollten spezifische Methoden im Quellcode untersuchen, um den Aufbau und die Validierung von URL-Pfaden zu verstehen, wie application:didFinishLaunchingWithOptions: und application:openURL:options:. Zum Beispiel verwendet Telegram verschiedene Methoden zum Öffnen von URLs:

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
}

Testen von URL-Anfragen an andere Apps

Methoden wie openURL:options:completionHandler: sind entscheidend, um URLs zu öffnen und mit anderen Apps zu interagieren. Die Identifizierung der Verwendung solcher Methoden im Quellcode der App ist der Schlüssel zum Verständnis externer Kommunikationen.

Testen auf veraltete Methoden

Veraltete Methoden zur Handhabung von URL-Öffnungen, wie application:handleOpenURL: und openURL:, sollten identifiziert und auf Sicherheitsimplikationen überprüft werden.

Fuzzing von URL-Schemata

Fuzzing von URL-Schemata kann Speicherbeschädigungsfehler identifizieren. Tools wie Frida können diesen Prozess automatisieren, indem sie URLs mit variierenden Payloads öffnen, um auf Abstürze zu überwachen, wie durch die Manipulation von URLs in der iGoat-Swift-App veranschaulicht.

$ 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

Hijacking von benutzerdefinierten URL-Schemata

Laut diesem Beitrag könnten bösartige Apps andere benutzerdefinierte Schemata von Apps registrieren, dann kann die bösartige App einen Browser öffnen, der alle Cookies der Safari-App mit ASWebAuthenticationSession hat.

Mit dem Browser kann die bösartige App eine von einem Angreifer kontrollierte Webseite laden, und TCC wird den mobilen Benutzer um Erlaubnis bitten, diese App zu öffnen. Dann könnte die bösartige Webseite auf eine Opferseite umleiten, zum Beispiel einen OAuth-Fluss mit dem Parameter prompt=none. Wenn der Benutzer bereits im OAuth-Fluss angemeldet war, wird der OAuth-Fluss das Geheimnis an die Opferanwendung unter Verwendung des benutzerdefinierten Schemas der Opfer-App zurücksenden.
Da die bösartige App es jedoch auch registriert hat und da der verwendete Browser innerhalb der bösartigen App ist, wird das benutzerdefinierte Schema in diesem Fall von der bösartigen App behandelt, die in der Lage sein wird, das OAuth-Token zu stehlen.

Referenzen

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