iOS Custom URI Handlers / Deeplinks / Custom Schemes
Reading time: 4 minutes
tip
Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Wsparcie HackTricks
- Sprawdź plany subskrypcyjne!
- Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.
Podstawowe informacje
Custom URL schemes umożliwiają aplikacjom komunikację za pomocą niestandardowego protokołu, jak szczegółowo opisano w Apple Developer Documentation. Te schematy muszą być zadeklarowane przez aplikację, która następnie obsługuje przychodzące URL-e zgodnie z tymi schematami. Ważne jest, aby walidować wszystkie parametry URL i odrzucać wszelkie źle sformułowane URL-e, aby zapobiec atakom przez ten wektor.
Podano przykład, w którym URI myapp://hostname?data=123876123
wywołuje określoną akcję aplikacji. Zauważona podatność występowała w aplikacji Skype Mobile, która pozwalała na nieautoryzowane akcje połączeń za pomocą protokołu skype://
. Zarejestrowane schematy można znaleźć w Info.plist
aplikacji w sekcji CFBundleURLTypes
. Złośliwe aplikacje mogą to wykorzystać, ponownie rejestrując URI, aby przechwytywać wrażliwe informacje.
Rejestracja schematów zapytań aplikacji
Od iOS 9.0, aby sprawdzić, czy aplikacja jest dostępna, canOpenURL:
wymaga zadeklarowania schematów URL w Info.plist
w sekcji LSApplicationQueriesSchemes
. Ogranicza to schematy, które aplikacja może zapytać, do 50, zwiększając prywatność poprzez zapobieganie enumeracji aplikacji.
<key>LSApplicationQueriesSchemes</key>
<array>
<string>url_scheme1</string>
<string>url_scheme2</string>
</array>
Testowanie obsługi i walidacji URL
Programiści powinni zbadać konkretne metody w kodzie źródłowym, aby zrozumieć konstrukcję i walidację ścieżek URL, takie jak application:didFinishLaunchingWithOptions:
i application:openURL:options:
. Na przykład, Telegram wykorzystuje różne metody do otwierania URL:
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
}
Testowanie żądań URL do innych aplikacji
Metody takie jak openURL:options:completionHandler:
są kluczowe do otwierania URL-i w celu interakcji z innymi aplikacjami. Identyfikacja użycia takich metod w kodzie źródłowym aplikacji jest kluczowa dla zrozumienia komunikacji zewnętrznej.
Testowanie przestarzałych metod
Przestarzałe metody obsługujące otwieranie URL-i, takie jak application:handleOpenURL:
i openURL:
, powinny być identyfikowane i przeglądane pod kątem implikacji bezpieczeństwa.
Fuzzing schematów URL
Fuzzing schematów URL może identyfikować błędy związane z uszkodzeniem pamięci. Narzędzia takie jak Frida mogą zautomatyzować ten proces, otwierając URL-e z różnymi ładunkami w celu monitorowania awarii, co ilustruje manipulacja URL-ami w aplikacji iGoat-Swift:
$ 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
Przechwytywanie niestandardowych schematów URL
Zgodnie z tym postem, złośliwe aplikacje mogą rejestrować niestandardowe schematy innych aplikacji, a następnie złośliwa aplikacja może otworzyć przeglądarkę, która ma wszystkie ciasteczka aplikacji Safari za pomocą ASWebAuthenticationSession.
Za pomocą przeglądarki złośliwa aplikacja może załadować stronę internetową kontrolowaną przez atakującego, a TCC poprosi użytkownika mobilnego o pozwolenie na otwarcie tej aplikacji. Następnie złośliwa strona internetowa może przekierować na stronę ofiary, na przykład w przepływie OAuth z parametrem prompt=none
. Jeśli użytkownik był już zalogowany w przepływie OAuth, przepływ OAuth wyśle sekret z powrotem do aplikacji ofiary, używając niestandardowego schematu aplikacji ofiary.
Jednakże, ponieważ złośliwa aplikacja również go zarejestrowała i ponieważ używana przeglądarka znajduje się wewnątrz złośliwej aplikacji, niestandardowy schemat będzie w tym przypadku obsługiwany przez złośliwą aplikację, która będzie mogła ukraść token OAuth.
Odniesienia
- https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0075/
- https://evanconnelly.github.io/post/ios-oauth/
tip
Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Wsparcie HackTricks
- Sprawdź plany subskrypcyjne!
- Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.