在iOS上，一個應用可以將其自身“綁定”到一個自定義URL Scheme上，該scheme用于從瀏覽器或其他應用中啟動該應用。如果是有用過《Launch Center PRo》和《Workflow》這類App的朋友，應該多少明白URLScheme的原理。

　　在正常的支付流程中，某個App(視頻上是美團)首先將訂單信息通過URL Scheme發(fā)送給支付寶(Alipay)，支付寶收到訂單信息，調用支付界面，用戶在支付寶上完成支付后，支付寶再發(fā)送一個URL Scheme給美團，美團收到付款信息后，顯示團購成功的界面。

　　在iOS系統(tǒng)中，多個應用程序注冊了同一種URLScheme的時候，iOS系統(tǒng)程序的優(yōu)先級高于第三方開發(fā)程序。但是一種URLScheme的注冊應用程序都屬于第三方開發(fā)，那么它們之間就沒有優(yōu)先級了。作者經過測試，證明系統(tǒng)判定優(yōu)先級順序與Bundle ID有關(一個Bundle ID對應一個應用)，如果有人精心偽造Bundle ID，iOS就會調用我們App的URL Scheme去接收相應的URL Scheme請求。

　　劫持過程：

　　演示視頻中“偽裝”成支付寶的“FakeAlipay”，在收到美團發(fā)來的訂單信息后，生成了一個和支付寶一樣的登陸界面，用戶在輸入帳號密碼后FakeAlipay 會把帳號密碼以及訂單信息發(fā)送到黑客的服務器上，黑客獲得這些信息后可以在自己的iOS設備上完成支付，并把支付成功的URL Scheme信息發(fā)回給FakeAlipay，FakeAlipay再把支付成功的URL Scheme信息轉發(fā)給美團。這樣就完成了一次被劫持的支付。

　　作者建議：(參考烏云原文及視頻介紹)

　　作者在文章中表示該漏洞利用簡單，修復卻非常復雜，所以在 iOS 8.2 上還是未能修復。但他還是提出了幾點建議讓開發(fā)者參考：

　　1.蘋果可以限制 iOS 應用不能注冊別的應用的 Bundle ID 作為 URL Scheme。這樣的話，使用自己的 Bundle ID 作為 URL Scheme 的接收器就會變的安全很多。

　　2.第三方應用可以通過①給自己發(fā)送 URL Scheme 請求來證明沒有被劫持，如果沒有收到自己的 URL Scheme，就可以及時給用戶發(fā)送提醒;②利用 MobileCoreServices 服務中的 applicationsAvailableForHandlingURLScheme() 來查看所有注冊了該 URL Schemes 的應用和處理順序，從而檢測自己、或者別人的 URL Scheme 是否被劫持。

　　果粉們只能等待官方新出的版本，更新BUG。