你不知道的iOS URL Scheme之唤起劫持篇（三）
本文讲的是iOS URL scheme的一个延伸应用。如果你对iOS URL scheme还不是很了解，建议可以先读一下《你不知道的iOS URL Scheme之基础篇（一）》，或者你更倾向于iOS URL scheme的典型应用，也可以先行读一下《你不知道的iOS URL Scheme之deeplink篇（二）》。这样可以更加方便的理解本文。
虽然这篇文章你可能会暂时应用不到，但还是建议大家先收藏，以后用到的时候，可以看看，有耐心的还是读一读，应该会对你有所启发。
本文旨在从技术上和大家一起交流分享，因为这样的唤起劫持总是不太好的，相信大家的志向是星辰大海，会自觉维护好本行业的规则。大家一起加油！
如果都准备好了，那我们就开始本文的黑科技唤起劫持之旅喽！
背景
由于苹果选择沙盒来保障用户的隐私和安全，App只能访问自己的沙盒，但同时也阻碍了App间合理的信息共享，所以苹果提供了一个可以在App之间跳转的方法：URL Scheme。iOS官方要求只有App本身定义了URL Scheme，iOS才会去识别跳转。iOS系统内置的App，如mail、电话和信息等等，都有相应的URL Scheme供其他的App调用。
但Apple的这一机制，存在一些缺点，如无统一标准和规范，一个App允许定义多个URL Scheme，任意命名等。也许这是Apple难得的开放，不过我们就暂且把它称之为缺点吧。所以当多个第三方App注册相同的URL Scheme时，系统识别唤起的对象就有可能发生变化，因此可以一定程度劫持热门App的唤起，从而实现唤起自身App。
技术可行性
iOS 官方说明：”在多个应用程序注册了同一种 URL Scheme 的时候，iOS 系统程序的优先级高于第三方开发程序。但是如果一种URL Scheme 的注册应用程序都是第三方开发的，那么这些程序的优先级关系是不确定的。”通过实验，确实满足官方说明的描述，对于多个第三方App注册相同的URL Scheme这一优先级关系不确定的情况，有时候表现为注册的先后关系，有时候表现为URL Scheme与bundle ID的相似度关系，总之优先级关系确实不确定。故通过在自身应用App中声明热门App的URL Scheme，从而实现劫持热门App达到唤醒自身App的方案，在技术上是可行的。
常用的iOS 热门App的URL Scheme
经收集及亲自实验，常用的iOS 热门App的URL Scheme收集如下：
| 系统APP | Scheme |
|---|---|
| SMS | sms |
| mailto | |
| iBooks | ibooks |
| Music | music |
| Videos | videos |
| 国内常用APP | Scheme |
|---|---|
| 支付宝 | alipay |
| 淘宝 | taobao |
| mqq | |
| 微信 | weixin |
| 美团 | imeituan |
| Keep | keep |
| 国外常用APP | Scheme |
|---|---|
| Chrome | googlechrome,googlechrome-x-callback |
| Gmail | googlegmail |
| fb,fbapi,fbauth2,fbshareextension | |
| Messenger | fb-messenger,fb-messenger-api |
| twitter,twitterauth | |
风险
-
苹果审核风险：弱
经查资料，App Store 上有大量的应用声明了 Chrome 以及 FaceBook 的 URL scheme，并且他们的开发者并不属于 Google 和 Facebook。这表明Apple 没有特别保护那些热门App的 URL Scheme ，上传的 App 无论声明什么样的 URL Scheme，苹果可能都会通过审核。 -
道义风险：强
通过URL Scheme协议唤起App，会弹出提示框，用户确认后才能启动应用。提示框中打开的对象App名称是真实要打开的App名称，即如果有App被劫持，存在以下两方面的道义风险：
- 用户是可以较轻易的察觉到真正打开的App名称是什么；
- 目的热门App的工作人员也较容易就发现是被哪一个App进行了劫持；
- 其他风险
结合我们常见的App通常含有向Facebook、twitter和instagram等平台的分享功能，所以还存在一个风险，即如果App添加了这几个平台的URL Scheme，会导致分享功能存在一定概率的无响应，而且该概率与劫持成功的概率相同，无法预期，相当于在劫持成功的情况下，自身唤起自身。
防护
从防护URL Scheme被劫持的角度，给我们的App有以下建议：
- 因为 Bundle ID 在 App Store 上是唯一的，应用注册URL Scheme可以采用 Bundle ID 或者Bundle ID的子集，尽可能确保唯一性。
- 提前检测自己应用的 URL Scheme 是否被劫持，即应用可以发送一条自身 URL Scheme 的请求给自己，如果自己可以接收到的话，说明 URL Scheme 没有被劫持，如果不能收到的话，就说明被劫持了，这时候可以提醒用户卸载有冲突的 app。
如果你喜欢我的文章，不要忘记关注我，谢谢大家了~
另外如果你要转载，希望可以注明出处，我会写出更多更好的文章，来回馈大家~
