全軍盡墨的Android應用：社會化授權登錄及分享安全漏洞

隨著微信微博等社會化媒體的火熱，第三方登錄迅速成為一種快捷注冊的方式，社會化分享也成為一種知識快速傳播的渠道。在移動端，幾乎大多數應用都接入了第三方登錄或者分享組件，尤其是微信、QQ、微博三大巨頭。這三者都提供了開放平台和SDK來幫助開發者接入這些功能，然而這些真的安全嗎？

---

一、漏洞發現

先說說場景吧，由於業務要求，需要對分享控件做了一次大的升級和重構，然後發現我們分享組件使用的是第三方的ShareSDK（專門封裝分享API的組件，大部分童鞋應該都聽說過），這本來也沒什麼問題。

然後，重構過程中遇到一個難以理解的事情，在工程assets目錄下面有一個名為ShareSDK.xml的文件，在打開這個文件之後，我震精了，喝到口的咖啡全噴到了鍵盤上，文件內容是這樣的：

第三方開放平台的應用注冊信息都是明文寫在這個文件中的，包括重要的AppId和AppSecret（圖內容來自是ShareSDK官方demo）。這個時候，第一個考慮的問題還僅僅是隱私暴露，並沒有考慮到安全漏洞方面。

當然，接下來就去看這樣設計的原因，原來是ShareSDK內部調用第三方應用授權分享需要這些應用注冊信息，為了方便開發者接入，所以采用這種文件靜態注冊的方式。<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPtf3zqrSu7j2v6q3otXfwM/Lvrv6o6zO3sLbysfWsb71yc+7ucrHv6q3otSt1PLJz6OstrzS/tL+vvW1w9Xi1ta3vcq9ysfT0NHP1tjOyszitcSho86qyrLDtMTYo7/S8s6qYXNzZXRzxL/CvNTatPKw/Ln9s8zW0MrH1K234rK7tq+12LTyvfhBUEuw/MTatcSjrMjOus7Iy7K70OjSqsjOus63tLHg0uu5pL7fvs3E3NaxvdO000FQS7D8xNrM4cihs/bAtKGjxMfDtKOsyOe5+9axvdPM4cihs/bAtLfFtb3B7dK7v+7TptPD1tDKx7K7ysfS4s6218UmaGVsbGlwOyZoZWxsaXA7PC9wPg0KPHA+z+u1vdXiwO+jrNLRvq2+qrP20rvJ7cDkurnBy6OsysC8zbTzv9OjocrAvM2087/To6HKwLzNtPO/07Cho6E8L3A+DQo8cD6908/CwLS+zcrH0enWpLXEuf2zzKOssr3W6LfHs6O88rWloaM8YnIgLz4NCjGhotXStb3Su7/uvdPI61NoYXJlU0RL1+m8/rXE06bTw6OsvavG5LCy17Cw/EFQS8TatcRTaGFyZVNESy54bWy94tG5zOHIobP2wLShozxiciAvPg0KMqGi1rG9072rz+7Ev7XEU2hhcmVTREsueG1szOa7u86qyc/Su7K9tcTOxLz+oaM8YnIgLz4NCjOhorX308O31s/tPC9wPg0KPHA+0enWpL3hufujurP9wcvOotDFz+C52LXEsrvE3LfWz+2jrFFRus3QwsDLtry31s/ts8m5psHLo6yyosfSz9TKvrfWz+3E2sjdwLTX1FhY06bTw6OsWFjTptPDvs3Kx87Sw8fM4cihtcTEx7/u06bTw8HLoaM8L3A+DQo8aHIgLz4NCjxwPjxzdHJvbmc+tv6hosKptrTUrdLyPC9zdHJvbmc+PC9wPg0KPHA+tbHIu6OsyOe5+732vfbKx9Xi0fmjrNa7xNzLtcrH0KHCqba0o6yyqLywt7bOp7Kisru546Gjv8nPp8rC0+vUuM6lo6zK0LOhyc85MCXS1MnPtcTTptPDtrzU2src1Na3ts6nxNqjrNSt0vK688Pmt9bO9qGjPC9wPg0KPHA+zqrBy7Dv1vrA7b3io6zO0sPHz8jAtMy40rvMuMnnu+G7r7fWz+21xLv61sahozwvcD4NCjxwPsrXz8ijrNK7v+7TptPD0qq908jryee74buvtcTK2siotcfCvLfWz+21yLmmxNyjrNDo0qq1vb+qt6LGvcyoyc/IpdeisuHTptPD0MXPoqOs16Ky4dDFz6Kw/MCo06bTw7D8w/ujrNOm08PHqcP7tci1yKOs0tTOotDFzqrA/aO6PC9wPg0KPHA+PGltZyBhbHQ9"這裡寫圖片描述" src="/uploadfile/Collfiles/20161003/20161003100024169.png" title="\" />

接著，應用注冊成功後，我們會得到兩個key，一個是AppId，一個是AppSecret（或AppKey）：

當然，一般情況下，移動應用只需要AppId，而AppSecret主要是用在接口API調用。為了安全起見，微信開放平台都已經不再存儲AppSecret，可想而知這些信息有多重要，所以在大家項目中無論是寫在Java代碼裡還是配置在xml中，只要是明文，都是萬萬不可行的！

那麼，第三方調用的機制流程是怎樣的呢，以微信為例：

步驟1：項目應用中集成微信SDK，也就是libammsdk.jar。
步驟2：通過AppId調用微信SDK發送請求，比如登錄授權、分享等。
步驟3：微信SDK將AppId、當前應用包名、請求信息發送到微信客戶端。
步驟4：微信客戶端接收到AppId後，請求服務端得到我們注冊在開放平台的應用包名、應用簽名、權限等。
步驟5：微信客戶端比對注冊的應用包名和步驟3中的應用包名，不一致調用失敗。
步驟6：微信客戶端比對注冊的應用簽名和請求應用的簽名（通過步驟3中的應用包名調用系統API查詢），不一致調用失敗。
步驟7：調用相應的API，比如登錄授權、分享等，當然還要看注冊的應用是否有這些權限。

其中最關鍵是步驟5和步驟6，正是因為有了這兩步的包名和簽名校驗，所以之前驗證漏洞時微信分享調用失敗。

新浪微博和QQ的第三方調用機制流程大同小異，但是QQ完全不做包名和簽名校驗，也就是省略了步驟5和步驟6，所以驗證漏洞時分享成功。

新浪微博比較特殊，因為其除了客戶端調用還是支持網頁端調用，所以驗證漏洞時調用客戶端分享失敗，調用網頁端分享成功。

綜上所述，校驗包名和校驗簽名是防止惡意調用的防御手段，QQ和新浪微博網頁這種不做校驗的方式都是存在安全隱患的，只需要知道特定應用的AppId，就可以以其名義發起惡意的授權登錄分享。遺憾的是，很多開發者不清楚AppId的重要性，直接暴露在代碼或文件中。

---

三、漏洞升級

前面說了，事情並不僅僅是這麼簡單。校驗包名和校驗簽名是防止惡意調用的防御手段，但是這種防御是否真的有用呢？

我們再來仔細梳理下流程，同樣以微信為例：

步驟3：微信SDK將AppId、當前應用包名、請求信息發送到微信客戶端。
步驟5：微信客戶端比對注冊的應用包名和步驟3中的應用包名，不一致調用失敗。
步驟6：微信客戶端比對注冊的應用簽名和請求應用的簽名（通過步驟3中的應用包名調用系統API查詢），不一致調用失敗。

這是其中最關鍵的三個步驟，微信客戶端接收到的AppId、應用包名都是來自微信SDK，而應用簽名是通過應用包名調用系統API獲取的，所以實質上校驗的來源只有AppId和應用包名兩個。

這裡面有一個非常重要的但又非常容易忽略的點就是：系統查詢到的應用簽名，可能並不是發起調用的應用，而是手機上安裝的指定包名的應用。 換言之，步驟3中發送到微信客戶端的AppId和應用包名，如果就是被惡意攻擊的應用的AppId和包名，並且手機上裝有這款被攻擊的官方應用，那麼步驟5和步驟6就全部被繞過了。

剩下的難點就是如何通過第三方SDK發送指定的AppId和包名給第三方客戶端了。

AppId容易得到，市場上幾乎所有應用裡面接入的社交化AppId都是明文形式寫在代碼裡面的，比如AndroidManifest.xml（天坑！天坑！天坑！）。

最後一步就是偽裝包名了，在Android中獲取當前應用包名都是通過Context.getPackageName的方式，開發者調用SDK的時候傳入的參數就有這個Context，那麼事情就變得無比簡單了！

另外，還有第二種方式，因為最終都是通過startActivity的方式調起第三方應用，參數都是通過Intent傳遞，我們可以在startActivity前將Intent中的參數包名替換掉，思路差不多，在此略過。

所以，只需要獲取到指定應用的包名，第三方AppId，就可以偽裝成這款應用發起第三方調用，而包名和AppId都是極其容易獲取的，當然為了繞過簽名校驗手機還必須裝有這款指定的官方應用。

---

四、漏洞危害

說完了漏洞，下面就要說這款漏洞的危害了，當然開發者節後也有的忙活了。

1、用戶隱私盜取

很多應用程序都接有第三方登錄授權的功能，有利於簡化用戶注冊過程。利用這個漏洞，攻擊者可以偽裝成官方應用騙取用戶授權，而且授權頁面是真真正正的授權頁，上面也確實顯示的是真正官方應用的logo和應用名。

授權成功之後，攻擊者拿到openId和access_token之後，再結合AppId和AppSecret，很容易就獲取到用戶的社交隱私，甚至如果抓包到接入第三方登錄功能應用的登錄接口，你的相關應用隱私也就一覽無余了。

相對來說，微信授權登錄還是比較安全的，因為授權結果是回調到WXEntryActivity的，由於應用applicationId的關系，回調的WXEntryActivity是難以被偽裝的，所以暫時還未想到其它攻擊手段，但依然是隱患。

2、虛假分享

和登錄授權不同，分享是不需要數據回調的，直接就分享出去了，那麼利用這個漏洞的可操作性就高了，而且非常簡單。

攻擊者可以給微信好友（群組）、朋友圈、QQ好友（群組）和新浪微博上肆意分享危害性質的信息網站鏈接，而在這些社交應用裡面，會顯示來自XX應用。比如利用此漏洞分享虛假新聞（來自XX頭條），分享虛假視頻（來自XX視頻），分享虛假話題（來自X乎），分享紅包優惠券（來自X東）等等。由於社交應用裡面顯示的是來自官方應用，所以可信任度非常高，真假難辨，騙取用戶點擊的幾率可謂是100%，如果是釣魚鏈接，後果難以想象。

---

五、漏洞反思

經過數個小時的測試，目前市場上主流應用都在此漏洞危害范圍之內，幾乎被全軍盡墨，能夠幸免的應用屈指可數，想想背後都是一身冷汗。

關於這個漏洞，從兩個層面來分析下修復策略吧。

1、開發者

這個漏洞原理並不復雜，其中一個重要的因素就是開發者直接暴露出去AppId甚至AppSecret，由於開發者安全意識不夠，未認識到它們的重要性。直接的後果就是暴露出去無法收回，即使後面版本處理了，歷史版本裡面仍然可以查到，可謂亡羊補牢為時晚矣！雖然這種事情難以避免，但仍然需要給我們一個血淋淋的教訓。在此，總結出以下兩點：

a、嚴禁明文暴露注冊第三方平台的AppId、AppSecret，包括文件、代碼、接口，至少要做一層簡單的加密。
b、接入ShareSDK授權登錄或分享的，必須在代碼中動態注冊AppId、AppSecret，同樣代碼中明文用的也應該是加密後的值。

2、第三方開放平台

首先，鄙視下手Q，竟然連包名和簽名都不校驗，也不知道是為了簡化開發者接入流程還是其它原因，這不是坑爹麼。

對於微信和新浪微博等開放平台，需要重新思考下校驗機制，目前的包名+簽名校驗方式肯定是不安全的了，當然現在是不可能整體更換方案了，修復針對點是保證授權分享調起者是真正的官方應用。個人有以下幾點建議：

a、增加Context的校驗，防止使用自定義的Context偽裝包名（最簡單）。
b、授權登錄回調禁用廣播監聽器等方式，使用指定Activity啟動回調，難以被攔截和偽裝，類似微信這種。
c、接口API調用嚴禁明文暴露調用發起者的AppId、AppSecret，比如微信授權時chromium的log就能抓到這些信息。
d、需要重視AppId，同時督促開發者保護好這些重要數據。

綜上所述，強烈建議開發者按照以上幾點排查和處理，同時希望第三方開放平台盡快更新SDK和客戶端，修復此漏洞。

最後，祝各位國慶節日快樂！

---

本博客不定期持續更新，歡迎關注和交流：

http://blog.csdn.net/megatronkings