mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
78 lines
5.2 KiB
Markdown
78 lines
5.2 KiB
Markdown
# iOS Custom URI Handlers / Deeplinks / Custom Schemes
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
## Podstawowe informacje
|
|
|
|
Custom URL schemes umożliwiają aplikacjom komunikację za pomocą niestandardowego protokołu, jak szczegółowo opisano w [Apple Developer Documentation](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW1). 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.
|
|
```xml
|
|
<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:
|
|
```swift
|
|
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](https://codeshare.frida.re/@dki/ios-url-scheme-fuzzing/) 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:
|
|
```bash
|
|
$ 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**](https://evanconnelly.github.io/post/ios-oauth/), 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](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/2990952-init#parameters).
|
|
|
|
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://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0075/)
|
|
- [https://evanconnelly.github.io/post/ios-oauth/](https://evanconnelly.github.io/post/ios-oauth/)
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|