0x00 前言
Apple在iOS中部署了沙箱机制，用来管理应用程序安全和隐私方面的问题。该机制限制了每个应用程序所能访问的资源，如果某个应用出现问题，就能将问题限制在一定范围内，通过App Store发布的所有app都受该机制约束。然而也是因为这种访问控制策略，app之间的通信会变得有些困难。
幸运的是，Apple精心设计了几种方法，帮助app之间相互通信，这里最常用的一种方法就是URL Scheme。从本质上讲，URL Scheme是一种实用功能，可以允许开发者通过URL在iOS设备上启动app。URL Scheme是将信息从一个app传到另一个app的一种方法。比如，当我们打开带有facetime://的URL时，就会发起FaceTime呼叫，这个场景中就用到了URL Scheme。这是非常方便的一条捷径，但URL Scheme主要是用于通信场景，并不是从安全性角度来设计的。
在本文中，我们将讨论如何滥用URL Scheme，实现隐私泄露、账单欺诈、以及弹出式广告等恶意场景。我们以中国区市场中的几款iOS应用为例（主要是WeChat即时通讯应用以及Suning网上购物应用，这里就不翻译了）来演示这种误用场景。与WeChat和Suning类似，还有其他很多应用具有相同功能，因此也受本文分析的这种攻击技术影响。我们向相关厂商（特别是WeChat）反馈并协同解决相关问题，也向Zero Day Initiative反馈了这些攻击技术。
0x01 工作原理
在iOS系统中，多个app可以声明同一个URL Scheme。比如，两个完全不同的app可以同时使用Sample://这个URL Scheme。这也正是某些恶意应用对URL Scheme的一种滥用方式，可以借此攻击最终用户。
Apple在后续iOS版本（iOS 11）中解决了这个问题，采用了先到先得原则，如果使用了同一个URL Scheme，只有先安装的app会被启动。然而，攻击者还是可以通过其他方法来利用这个漏洞。
账户隐私泄露
我们可以把URL Scheme看成是app用来接收其他app信息的一个门户。前面提到过，由于Apple允许不同app声明相同的URL Scheme，因此恶意app可以劫持特定app的敏感数据。如果app A的登录过程与app B关联起来，那么这个漏洞就显得非常严重。
举个例子，比如Suning app允许受害者使用自己的WeChat账户来登录。正常的身份认证过程如下图所示，Suning app生成一个URL Scheme查询，将其发送给WeChat app。当WeChat app收到来自Suning app的查询时，会向WeChat服务器请求一个Login-Token（登录令牌），然后将该令牌发回Suning app，完成认证过程。
图1. Suning app使用WeChat账户登录过程
我们研究后发现，Suning会使用相同的Login-Request URL Scheme查询来请求Login-Token，但WeChat并没有验证登录请求的源。这样一来，攻击者就可以滥用某个app的Login-Request URL Scheme发起攻击。
比如，攻击者可以使用Suning的Login-Request URL Scheme查询来请求受害者WeChat账户的Login-Token，然后利用这个令牌，以受害者WeChat账户的身份登录Suning（如下图所示）。这个过程可以允许攻击者收集个人信息，或者滥用这两个账户的访问权限。
图2. 恶意攻击者使用受害者WeChat账户登录Suning app
为了使这种攻击方法完美实施，攻击者首先必须要得到Suning的Login-Request URL Scheme。如果想从Suning app获取该信息，攻击者需要以WeChat的URL Scheme来创建一个完全独立的app（我们可以在Suning app的Info.plist中，通过LSApplicationQueriesSchemes找到WeChat的URL Scheme）。利用合法的Wechat URL Scheme，攻击者可以伪造一个WeChat app，这样Suning就会向伪造的app请求Login-Token。
如果Suning app发送了请求，那么伪造的app就可以捕获相应的Login-Request URL Scheme。经过分析后，我们发现这个Login-Request会在多个查询轮次中包含常量参数以及常量值，这样攻击者就有机会重放请求。
图3. 从Suning到WeChat的Login-Request
图4. 从WeChat到Suning的Login-Token
如图3及图4所示，Suning在构造查询字符串时，会插入一个独特且复杂的URL Scheme（即wxe386966df7b712ca），以便WeChat响应。WeChat端会将这个URL注册为Suning登录专用。WeChat虽然能够识别该URL，但并不会去认证发送Login-Request的源。相反，WeChat会直接向请求源返回一个Login-Token。
不幸的是，这个源app也可能是滥用Suning URL的恶意app。
图5. 恶意app通过URL Scheme攻击窃取Login-Token
利用这个Login-Token，恶意攻击者可以访问受害者的WeChat账户，窃取个人信息。攻击者可以在其他攻击活动中使用已窃取的账户。
这个问题并不局限于这两个app，还有许多app采用了这种登录功能，因此也存在这个漏洞。
账单欺诈
伪造的URL Scheme也可以用于多个攻击场景，比如账单重放欺诈攻击，攻击者可以诱骗受害者支付其他人的账单。这种攻击需要使用社会工程学技巧以及URL Scheme漏洞。
通常情况下，如果某些app带有支付功能，攻击者可以向这些app发送账单对应的URL Scheme来发起账单重放欺诈攻击。这里我们以DiDi或者MeiTuanDaChe（这两个app都是交通出行app，这里就不翻译了），再搭配带有支付功能的某个app为例，来演示这种攻击方法。
为了重现这种攻击，我们以WeChat作为支付app来演示其中存在的问题。我们还没在实际环境中看到攻击者用过这种攻击方法，但只要指定参数，攻击就有可能成功。攻击者可以使用前文提到的策略：伪造一个WeChat，与合法应用带有相同的URL Scheme，然后抓取来自DiDi或者MeiTuanDaChe的URL Scheme支付请求。
利用支付URL Scheme，攻击者可以向任意合法WeChat app重放支付请求，而该app会自动唤起支付接口。由于攻击者使用的是从DiDi或者MeiTuanDaChe窃取的（但是合法的）URL Scheme请求，因此受害者端合法的WeChat app会接受这个支付请求。
图7. 重放URL Scheme
不可否认的是，正常用户可能不会被欺骗，因为用户不大可能会去支付在WeChat支付接口中随机弹出的支付请求。即便如此，这种方式极大增加了用户被欺诈攻击的可能性。用户有可能不小心点了支付按钮，或者可能误认为这是合法的付款请求。
这里也可能存在另一种攻击场景，比如结合使用SMS（短信）社会工程学技巧以及URL Scheme。以这些app为例，攻击者可以利用这种支付请求。
如果用户用过DiDi或者MeiTuanDaChe app，那么经常会收到短信，提醒用户尚未完成订单支付。攻击者可以向受害者发送相同的SMS消息，其中包含某个支付请求的URL Scheme（这个支付请求可以是攻击者构造的任意请求）。该链接会重定向到WeChat的支付接口，要求用户完成支付。这是攻击受害者的一种好方法，可以诱骗用户支付他人账单。
图8. 依托SMS消息的账单重放欺诈攻击
幸运的是，最新版的WeChat部署了一种新的安全策略，可以避免这种支付重放攻击：如果支付请求来自于MobileSafari，WeChat将不再接受该请求。然而，如果支付请求源自于Chrome、Message、Gmail等其他app，那么账单重放攻击依然可行。
弹出式广告
URL Scheme还有另一个问题，就是可以用来启动应用程序。这意味着一旦恶意app注册了特定的URL Scheme，那么当这个URL Scheme被调用，就有可能启动恶意app。在研究过程中，我们系统识别出了大量app，这些app都会利用这种方式来向用户展示广告。
恶意app可以声明与其他流行应用象关联的URL Scheme，比如wechat://、line://、fb://、fb-messenger://等，我们也找到了许多潜在恶意的app，如下所示：
| SHA256 | Bundle ID | 声明的URL Scheme数量 |
|---|---|---|
| 1377742266f2a56f0424c1884c9c1fab8daa113b51c7f4d2ac4b2f88b770a1f5 | co.Mu.Mu | 490 |
| c329fc984a2d75e4f1f15288cb5d9383c2f439dbae67bf808759bc5bc8336aee | co.medaistream.pokemap2 | 430 |
| 93326edbbd8863fbb0d2e602e1d8a7348349053ae144912286e78fb17a685c0f | co.musical.Musical | 491 |
| fe8fe4226ba17924cd31505a07b19691b5eecf2e9ae677bc9765130020662b89 | com.musictechnology.Musia | 491 |
0x02 缓解措施
URL Scheme可能非常危险，不建议用于传输敏感数据。由于通信过程及数据传输中并没有考虑源或目的app，因此攻击者可以利用这种未授权功能发起攻击。
当我们首次发现该漏洞时，就分别于2018年6月及8月向受影响厂商反馈相关信息，并且我们还注意到受影响的许多应用实际上来自于中国区的App Store。Apple也意识到了这种威胁，官方向开发人员通报了URL Scheme存在的危险，并提供了相应建议。官方提到：“URL Scheme可能使您的应用存在潜在的安全风险，因此请确保您充分验证所有URL参数，丢弃格式错误的任何URL。此外，请限制应用的操作范围，避免用户数据受到影响”。
对于开发者而言，我们建议应用在深度链接场景中使用通用型链接，设置通用链接登录接口（HTTP或者HTTPS），使用随机标识符在本地认证收到的登录令牌，避免劫持以及恶意登录令牌重放攻击。