iOS Custom URI Handlers / Deeplinks / Custom Schemes
Basic Information
自定义 URL 方案使应用程序能够使用自定义协议进行通信,详细信息请参见 Apple Developer Documentation。这些方案必须由应用程序声明,然后处理遵循这些方案的传入 URL。至关重要的是 验证所有 URL 参数 并 丢弃任何格式不正确的 URL 以防止通过此向量进行攻击。
给出了一个示例,其中 URI myapp://hostname?data=123876123
调用特定的应用程序操作。一个已知的漏洞出现在 Skype Mobile 应用程序中,它允许通过 skype://
协议进行未授权的呼叫操作。注册的方案可以在应用程序的 Info.plist
中的 CFBundleURLTypes
下找到。恶意应用程序可以通过重新注册 URI 来拦截敏感信息。
Application Query Schemes Registration
从 iOS 9.0 开始,要检查应用程序是否可用,canOpenURL:
需要在 Info.plist
中的 LSApplicationQueriesSchemes
下声明 URL 方案。这将应用程序可以查询的方案限制为 50,从而通过防止应用程序枚举来增强隐私。
测试 URL 处理和验证
开发者应检查源代码中的特定方法,以了解 URL 路径构造和验证,例如 application:didFinishLaunchingWithOptions:
和 application:openURL:options:
。例如,Telegram 使用多种方法来打开 URL:
测试对其他应用的 URL 请求
像 openURL:options:completionHandler:
这样的方法对于打开 URL 以与其他应用交互至关重要。识别应用源代码中此类方法的使用是理解外部通信的关键。
测试已弃用的方法
处理 URL 打开的已弃用方法,如 application:handleOpenURL:
和 openURL:
,应被识别并审查其安全影响。
模糊测试 URL 方案
模糊测试 URL 方案可以识别内存损坏漏洞。像 Frida 这样的工具可以通过打开具有不同有效负载的 URL 来自动化此过程,以监控崩溃,示例为 iGoat-Swift 应用中 URL 的操控:
自定义 URL 方案劫持
根据 这篇文章,恶意应用可以 注册其他应用的自定义方案, 然后恶意应用可以使用 ASWebAuthenticationSession 打开一个包含 Safari 应用所有 cookies 的浏览器。
通过浏览器,恶意应用可以加载攻击者控制的网页,TCC 将询问移动用户是否允许打开该应用。然后,恶意网页可能会重定向到受害者页面,例如带有参数 prompt=none
的 OAuth 流。如果用户已经登录了 OAuth 流,OAuth 流将使用受害者应用的自定义方案将密钥发送回受害者应用。
然而,由于恶意应用也注册了它,并且所使用的浏览器在恶意应用内部,因此在这种情况下,自定义方案将由恶意应用处理,恶意应用将能够窃取 OAuth 令牌。
参考文献
Last updated