目前有很多 APP 應用都會使用到由其他 APP 提供的服務，例如大家經常會用到的微信登錄、Facebook 登入、支付寶支付、微信支付等等。
在 iOS 中提供了以 URL Scheme 的方法以喚起其他第三方 APP， 基本使用方法和實現代碼較簡單，在這裡就不再介紹。
而本文將會集中介紹於以 URL Scheme 跳轉到其他第三方 APP 時，由於 iOS 的機制問題，有機會出現 APP 被劫持的情況。
正常跳轉流程
首先我們來看一下一般正常情況下，URL Scheme 的喚起流程，應用 A 以 B 的 URL Scheme 喚起 應用 B 並傳遞相關內容，然後在應用 B 中完成相應操作，再將數據透過 A 的 URL Scheme 返回並傳遞相關內容到應用 A。 這樣就完成了一個正常相互跳轉的流程。
跳轉問題
大家都知道，如果用這樣方式跳轉到其他 APP 應用，iOS 系統根據的是在應用的 info.plist 文件中自行定義的 URL Scheme （例如：weixin(微信), alipay(支付寶), fb(Facebook)......）及在 LSApplicationQueriesSchemes 中加入允許其他第三方指定應用喚起的 URL Scheme。
這樣問題就來了，如果手機中同時存在有兩個應用都使用相同的 URL Scheme，那麼原來應用喚起目標應用時，系統到底會先喚起哪一個呢？
由於 iOS 是封閉的系統，所以無法得知真實的 URL Scheme 優先級順序，但根據實驗可以得出
URL Scheme 的優先級：如果具相同的 URL Scheme ，則按應用的 Bundle Identifer 的優先級順序，而且 Apple 官方系統應用的 Bundle Identifer > 按應用的 Bundle Identifer 字母由 a 至 z 順序
所以，假如手機上存在一個惡意劫持應用 C，它使用與應用 A 相同的 URL Scheme，但是將 Bundle Identifer 設定得比應用 A更要靠前，這樣，會發生什麼情況？
透過這個方式，就可以成功地讓應用 C "冒充"成應用 A，而被 應用 B 喚起，同時 應用 C 亦會得到 應用 B 所傳遞過來的內容，完成內容截取的動作。
存在資料被篡改的風險
反過來，亦可以冒充為應用 B 進行劫持，讓應用處理結果透過到 惡意應用 D 進行篡改，送回給應用 A，完成偽造數據。想像一下，如果 應用 A 要喚起 應用 B 進行支付動作，那麼 應用 A 則會傳遞 訂單資訊（比如訂單編號、金額等的資料）給 應用 B，然後我們用 惡意應用 C 截取了這些數據及進行篡改（比如修改了金額），並重新簽名，接著再透過相同的方式，將篡改後的數據送回給 應用 A，那麼這樣就很危險了。
當然，現時很多大公司及較知名的應用，例如支付寶、微信等都已針對這個問題進行處理，但亦有些應用經測試後，是能夠成功截取及篡改敏感資料的。所以可以得出使用 URL Scheme 喚起應用並傳遞內容，是不一定可靠的。
加固方法
以下有這幾種方法可以預防這種情況發生，根據實際需要使用其中一種或多種混合使用：
- 使用 KeyChain 傳遞敏感內容
- iOS 的 KeyChain 是一種相對比較安全的儲存數據方式，可以透過在 XCode 的 Keychain Sharing 方法，在不同的應用中使用同一張證書，即可實現數據共享，很適合用作同一企業下不同應用之間的互通，比如說登入了 A 應用之後，使用同一張證書的 B 應用就已經自動登入了，這種效果，就是使用 Keychain 來共享及傳遞數據。更可以用 Keychain 配合 URL Scheme 方式來安全地傳遞數據，例如在 URL Scheme 中，傳遞的只是KEY，而非明文數據。
- 當然，強烈建議即使使用 Keychain Sharing 的方式儲存或共享數據，也必須要先加密再儲存到 Keychain中。另外，當應用把數據寫入 KeyChain 後，即使被刪除了，數據亦不會消失。
- 對傳遞內容進行加密
- 在傳遞數據前，應該先使用各種對稱或非對稱的加密算法對數據內容進行加密，同時更應該在應用中妥善保管密鑰和構造具混淆性的簽名方式，以免被進行惡意構造數據再進行重新簽名，以及還應該在服務器方面增加一些檢查機制，比如說核對一下返回的訂單內容（比如說簽名、訂單金額等）是否一致等等。
- 應用自我檢查[cce][[UIApplication sharedApplication] openURL:[NSURL URLWithString:@“[scheme]://checking“]];[/cce]
- 判斷系統中 URL Scheme 的順序
[cce]Class LSApplicationWorkspace_class = objc_getClass(“LSApplicationWorkspace”);
NSObject *ws = [LSApplicationWorkspace_class performSelector:@selector(defaultWorkspace)];
NSLog(@”openURL: %@”,[workspace performSelector:@selector(applicationsAvailableForHandli ngURLScheme:)withObject:@”[scheme]”]);[/cce]
總結
URL Scheme 無疑是一種很簡單地跳轉到第三方應用的方式，使用上雖然簡單，但是相對較容易地截取及篡改，如果原應用所調用及傳遞的數據是相對敏感的，應該先考慮以上幾種加固方法，以預防數據被截取，甚至被篡改再傳回原應用，達到欺騙原應用的效果，造成損失。所以如果需要在多個應用中共享或傳遞數據，個人還是相當建議搭配 Keychain 使用，它將能夠較好地保護數據，當然，無論使用哪一種方法，還者是搭配使用，在儲存敏感數據時，加密儲存和在應用中妥善保管密鑰和構造具混淆性的簽名方式是必要的。