2017-10-23

URL scheme:

app 之间交流的通道，它是由一个app定义的与其它app进行交流的简单协议。app在它的plist文件中声明它，其它app可以通过这个url scheme 向该app传递参数和执行该App。这个url scheme被浏览器或者其它app内的webview组件触发，一个目的地址是这个url 地址部分（例如：yelp:）的http重定向就会发生。然后传递的这个URL的数据部分就会将声明这个scheme的app激活。

Apple中的策略列表包含系统策略列表和其它策略列表。系统策略不能被任何第三方的app再声明，其它策略声明在用户授权下被修改（例如：打开http链接的默认浏览器），对于不在列表上的策略，在OSX上，它将会与第一个注册它的app绑定，而在iOS上则正好相反。所以在iOS上，恶意应用可以轻易截取目标App的scheme和传向它的数据，即使恶意应用在目标应用之后安装。

在OS X上，可以通过API URLForApplicationToOpenURL、LSCopyDefaultHandlerForURLScheme返回那个注册了已有scheme的app的 bundle id，然而在iOS上没有类似的API可以调用。因此，在没有os-level的支持下，app 就不能通过这个URL来认证它将要执行的app是不是自己想要的。所以，所有运行在iPhone和iPad上的第三方应用都很容易受到威胁，而Apple官方好像也从没有要求过App开发商区分哪些可以通过URL登录的App，也没有在App store上检查apps是不是有相同的scheme定义。

案例：通过FaceBook 拿到 用户的 Pinterest 账号密码等信息

Facebook 触发了scheme并同时发送秘密数据给这个App ：fb274266067164://access_token=CAAAAP9uIENwBAKk&xX=Y ，在研究中使用恶意App接管了这个scheme；然后结果就是FaceBook登录上恶意App，并将传送给Pinterest的秘钥，传送给了恶意应用。实际上，登录FaceBook的scheme也可以被劫持，这样恶意应用就会转变成“中间人攻击”，整个过程通过它的webview组件代替真正地FaceBook实现App的SSO（single sign on）登录。最重要的是，一旦恶意应用拿到FaceBook的秘钥，然后通过fb274266xxxx://传送给Pinterest,从而使用户完全不知道攻击来自于何处。

在这个案例中的最后一步即恶意应用将秘钥通过fbxxxxx://传送给Pnterest，可以通过API openURL: sourceApplication参数,将激活该scheme communication应用的bundle ID返回给Pinterest

在 自定义了URL scheme 的应用中，app delegate必须实现以下方法（在App通过URL被唤醒时，该函数是首先被调用的函数）:

-(BOOL)application:(UIApplication*)application 
openURL:(NSURL *)url 
sourceApplication:(NSString *)sourceApplication 
annotation:(id)annotation


sourceApplication 可以返回发起调用的App的bundle id，通过sourceApplication这个参数，可以验证发起调用的App是否合法。

[url sceme] 可以返回 URL scheme

[url query] 可以返回传递的参数信息

关于URL scheme 优先级：优先级和App的Bundle identifier有关，更准确说和Bundle identifier的字母排序有关，如果精心设计这个id，我们就可以做到截获其他应用的URL。

OS X, between the claim and the use, the app can run URLForAPPlicationToOpenURL or LSCopyDefaultHandlerForURLScheme

to find out which app will be launched by a given scheme. But for IOS, an app doesn't have any means to find out the owner of a scheme.

产生漏洞的根源在于这个URL并非是应用唯一的。apple并没有任何限制或者审核这个URL的任何措施，也就是说，如果两个App有着相同的URL Schemes，那么系统唤起的App可能并不是你想唤起的。

2016.9.14 苹果发布iOS 10升级，测试不受BadURLScheme漏洞影响。

Scheme白名单:

从iOS9.0后，涉及到平台客户端的跳转，系统会自动到info.plist下检查是否设置Scheme。如果没有做相应的配置，就无法跳转到相应的客户端。因此如果客户端集成有分享与授权，需要配置Scheme白名单。

检测方法：

理论上来说，url scheme 名字越不常见，重复率越低。对于每个App，扫描它的plist文件，找到它注册的URL scheme 名字，与数据库中已有的对比，若有重复，危险；若无，加入数据库，安全。