mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
78 lines
5.1 KiB
Markdown
78 lines
5.1 KiB
Markdown
# iOS Custom URI Handlers / Deeplinks / Custom Schemes
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
## Informações Básicas
|
|
|
|
Os esquemas de URL personalizados permitem que aplicativos se comuniquem usando um protocolo personalizado, conforme detalhado na [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). Esses esquemas devem ser declarados pelo aplicativo, que então lida com URLs de entrada seguindo esses esquemas. É crucial **validar todos os parâmetros de URL** e **descartar quaisquer URLs malformadas** para prevenir ataques através desse vetor.
|
|
|
|
Um exemplo é dado onde o URI `myapp://hostname?data=123876123` invoca uma ação específica do aplicativo. Uma vulnerabilidade notada estava no aplicativo Skype Mobile, que permitia ações de chamada não autorizadas via o protocolo `skype://`. Os esquemas registrados podem ser encontrados no `Info.plist` do aplicativo sob `CFBundleURLTypes`. Aplicativos maliciosos podem explorar isso re-registrando URIs para interceptar informações sensíveis.
|
|
|
|
### Registro de Esquemas de Consulta de Aplicativos
|
|
|
|
A partir do iOS 9.0, para verificar se um aplicativo está disponível, `canOpenURL:` requer a declaração de esquemas de URL no `Info.plist` sob `LSApplicationQueriesSchemes`. Isso limita os esquemas que um aplicativo pode consultar a 50, melhorando a privacidade ao prevenir a enumeração de aplicativos.
|
|
```xml
|
|
<key>LSApplicationQueriesSchemes</key>
|
|
<array>
|
|
<string>url_scheme1</string>
|
|
<string>url_scheme2</string>
|
|
</array>
|
|
```
|
|
### Testando o Manuseio e Validação de URLs
|
|
|
|
Os desenvolvedores devem inspecionar métodos específicos no código-fonte para entender a construção e validação de caminhos de URL, como `application:didFinishLaunchingWithOptions:` e `application:openURL:options:`. Por exemplo, o Telegram utiliza vários métodos para abrir URLs:
|
|
```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
|
|
}
|
|
```
|
|
### Testando Requisições de URL para Outros Apps
|
|
|
|
Métodos como `openURL:options:completionHandler:` são cruciais para abrir URLs e interagir com outros apps. Identificar o uso de tais métodos no código-fonte do app é fundamental para entender as comunicações externas.
|
|
|
|
### Testando Métodos Obsoletos
|
|
|
|
Métodos obsoletos que lidam com a abertura de URLs, como `application:handleOpenURL:` e `openURL:`, devem ser identificados e revisados quanto às implicações de segurança.
|
|
|
|
### Fuzzing de Esquemas de URL
|
|
|
|
Fuzzing de esquemas de URL pode identificar bugs de corrupção de memória. Ferramentas como [Frida](https://codeshare.frida.re/@dki/ios-url-scheme-fuzzing/) podem automatizar esse processo abrindo URLs com diferentes payloads para monitorar por falhas, exemplificado pela manipulação de URLs no app 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
|
|
```
|
|
## Sequestro de esquema de URL personalizado
|
|
|
|
De acordo com [**este post**](https://evanconnelly.github.io/post/ios-oauth/), aplicativos maliciosos poderiam **registrar esquemas personalizados de outros aplicativos,** então o aplicativo malicioso pode abrir um navegador que possui todos os cookies do Safari App com [ASWebAuthenticationSession](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/2990952-init#parameters).
|
|
|
|
Com o navegador, o aplicativo malicioso pode carregar uma página da web controlada pelo atacante e o TCC pedirá ao usuário móvel permissões para abrir esse aplicativo. Então, a página da web maliciosa poderia redirecionar para uma página da vítima, por exemplo, um fluxo OAuth com o parâmetro `prompt=none`. Se o usuário já estiver logado no fluxo OAuth, o fluxo OAuth enviará o segredo de volta para o aplicativo da vítima usando o esquema personalizado do aplicativo da vítima.\
|
|
No entanto, como o aplicativo malicioso também o registrou e porque o navegador usado está dentro do aplicativo malicioso, o esquema personalizado será tratado neste caso pelo aplicativo malicioso, que será capaz de roubar o token OAuth.
|
|
|
|
## Referências
|
|
|
|
- [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}}
|