從最近幾年開始，做平臺的公司都流行起Open API。這是一個非常好的理念，也受到廣大開發者的歡迎。如今，開發一款軟件，你可以很容易地集成微博、微信、人人網等流行社交媒介的分享功能，做一個社交應用變得越來越簡單。
主流社交媒介要集成到第三方應用中，最重要的入口就是安全便捷的授權認證系統。讓用戶在享受一鍵分享和各種社交樂趣的同時，又不用擔心帳號安全和隱私泄露等問題。而對于一些有特殊目的的組織或個人來說，攻占這個授權認證系統意味著自己獲取了信息傳播的入口和渠道，數量龐大地社交入口往往能帶來巨大的社會效應。所以，這個入口就成了軟件安全攻防雙方的必爭之地。
而本文所要講的就是當前最為流行的新浪微博Android客戶端SSO授權認證入口的一個安全缺陷。此缺陷使得第三方APK在一定條件下可以不通過授權，在不需要人為操作的情況下就可以操作Android手機用戶的微博。包括關注、評論、發微博等OpenAPI中提供的功能。
一、新浪微博授權認證方式的演變：
首先讓我們簡單回顧一下新浪微博OpenAPI這幾年授權認證方式的演變歷程，并了解一下各自的安全性問題。
1、最開始是Basic認證。
即是通過http協議的authorization頭來傳遞認證信息。認證信息包括用戶名和密碼，僅通過base64對用戶名密碼做加密。基本相當于明文傳輸。所以出于賬戶安全考慮，經過一段時間后就被廢棄不用了。
2、然后切換為XAuth認證。
XAuth認證其實就是OAuth認證的簡化版。OAuth的原理不做詳細說明。大致流程是：
A、第三方應用到授權服務器請求一個授權令牌(request token&secret)
B、引導用戶到授權服務器請求授權
C、用訪問令牌到授權服務器換取訪問令牌(access token&secret)
D、用訪問令牌去訪問得到授權的資源
它的安全保障是，所有http請求都采用非對稱加密算法對請求進行了加密。所以網絡上傳輸的數據理論上是安全的。
但XAuth認證是OAuth認證的簡化版，它允許第三方應用從用戶的輸入中獲取到用戶的帳號和密碼，而無法保證第三方應用對用戶的帳號和密碼進行了足夠安全地保護。特別還有一些流氓軟件本身就會記錄用戶的信息。所以微博帳號的安全還是存在較大的風險。
3、采取了更安全更便捷的OAuth2.0認證。
OAuth2.0比OAuth1.0更安全更便捷主要是兩個方面。
更便捷。OAuth2.0的認證流程比OAuth1.0更簡單。只需要三步：
A、引導用戶到授權服務器，請求用戶授權，用戶授權后返回 授權碼(Authorization Code)
B、客戶端由授權碼到授權服務器換取訪問令牌(access token)
C、用訪問令牌去訪問得到授權的資源
更安全。token不再需要secret，并且也不再需要對token進行加密。但OAuth2.0采用了https安全協議，在安全保障更勝一籌。
并且OAuth2.0第三方應用不再接觸到用戶的帳號和密碼，用戶直接跳轉到新浪微博的認證界面進行登錄。第三方應用僅獲取登錄成功之后的結果。從而保障了用戶帳號的安全。
但是OAuth2.0認證在移動終端的應用上也存在一定問題。主要倒不是安全上的，而是用戶體驗上的。跳轉到授權頁面在移動終端上體驗不好，授權流程相對復雜，導致授權的轉化率受到影響。因此，新浪微博結合新浪微博客戶端一起推出了它的第四代授權認證：SSO認證。
4、通過微博客戶端的SSO認證。
SSO的全稱是Single Sign On，中文名是單點登錄。當第三方應用與新浪微博客戶端為互相信任的應用系統時，僅需要一次授權登錄就可以在一定期限內，不再重復登錄授權而不受限制地調用新浪微博Open API提供的各種服務。
這種授權方式與新浪微博客戶端緊密結合，當用戶有登錄新浪微博客戶端時，只需要一鍵授權就能完成授權流程，非常便捷。另外第三方應用通過微博客戶端進行授權認證，不會直接接觸到用戶的賬號密碼，賬戶安全也能得到保障。
SSO是一種非常好的移動終端認證方式，并且利于本身客戶端的推廣。安全性和便捷性都不錯。但由于SSO的基礎是客戶端和第三方應用需要互相信任，而這個信任關系本身的安全性存在缺陷。因此就會出現其他非信任應用能夠冒充信任應用獲得授權認證，從而對用戶的微博進行操作的情況。這就是我們本文中將做進一步闡述的內容。
二、如何冒充信任應用，獲取客戶端的授權：
在Android應用中使用過新浪微博SSO認證的朋友們都知道，針對新浪微博的授權，官方提供了較詳細的文檔和封裝得足夠簡單的SDK供大家使用。由于本文內容與這些技術細節關系不大，所以在此就不做細述，不了解的朋友可以去新浪微博開放平臺的官網上了解相關內容。
事實上，新浪微博對于信任應用的認證環節相當地弱。具體來說只需要兩個關鍵信息：CONSUMER_KEY和REDIRECT_URL。
CONSUMER_KEY即第三方應用在新浪微博開發平臺網站后臺申請到的APP KEY。
REDIRECT_URL即第三方應用在后臺填寫的OAuth2.0的授權回調頁網址。
當這兩個信息匹配時，新浪微博就會認為是對應的第三方應用發起了合法的請求。授權流程就會正常進行。如果這個第三方應用已經在之前做過了授權，那么它就可以直接獲取access_token，然后就可以操作用戶的微博了！
現在我們假設：
1、用戶的Android手機已經安裝了新浪微博客戶端并已經登錄。（應該95%以上的手機滿足此假設吧）
2、用戶曾授權過一些主流第三方應用進行微博分享操作。例如camera360、美圖秀秀、網易新聞等。（此假設應該也有90%以上的用戶滿足吧）
3、用戶的新浪微博端只登錄了單用戶帳號。多用戶帳號在SSO授權時需要用戶手動選擇帳號，所以需要人為干預。（此假設也應該有90%左右用戶滿足吧）
在滿足前面三個條件的情況下，只需要我們再獲取到用戶曾經授權過的第三方應用的CONSUMER_KEY和REDIRECT_URL就可以通過官方的SDK調用，在不需要人為操作的情況下操作Android手機用戶的微博了！
于是我們的問題集中在了如何獲取第三方應用的CONSUMER_KEY和REDIRECT_URL上。
很多朋友也許會認為，CONSUMER_KEY和REDIRECT_URL對于SSO授權認證系統的地位就相當于非對稱加密算法的私鑰，屬于非常隱私的、應該被保密起來的信息，我們如何可以獲取到呢？
這里需要注意的是，私鑰之所以安全，是因為它是物理隔離的。私鑰的信息理論上只存在于軟件發布商的單機上，任何發布到公眾的信息中都不包含私鑰信息。因此，除非特殊途徑（例如拿到軟件發布商的電腦把私鑰拷貝出來，或者軟件發布商頭腦發暈，把私鑰給發了出去），我們認為私鑰信息是絕對安全的。
而CONSUMER_KEY和REDIRECT_URL是授權過程中需要的信息，因此把必須在軟件的運行時出現，因此這個信息從理論上來講是發布到公眾的信息。通過一系列逆向、靜態、動態分析，我們可以獲取到這些信息。因此它是不安全的。
正巧，幾個月前閑暇之時，曾對一些如今比較流行的Android應用做過這方面的技術分析。自己通過逆向獲取到了這些應用的相關信息，如下圖：
注：沒列出來的應用并不證明沒有此安全問題。
這些應用都是現在最為流行的一些應用。為了不引起公眾影響，我對其中的關鍵信息進行了適度的隱藏。
因此只要你曾經授權這些第三應用（以及其他第三方應用），那么從理論上來說，軟件安全的攻方，就可以通過逆向獲取這些應用的CONSUMER_KEY和REDIRECT_URL，通過官方提供的SDK，在你不知情的情況下，操作你的新浪微博帳號了。
三、新浪微博的下一代授權認證方式：
針對目前SSO授權認證安全缺陷的情況，新浪微博推出了下一代SSO認證，即SSO2.0。
事實上SSO授權認證從去年推出以來，這個問題很快就被發現，如果不是現在推出了SSO2.0，我可能還會繼續憋著不說。畢竟破解不是關鍵，關鍵是推動軟件安全不斷進步。
在理解了現在的SSO授權認證機制及其缺陷后，SSO2.0很好理解。SSO2.0主要就是為了防止非信任的第三方應用冒用信任的第三方應用的身份。既然CONSUMER_KEY和REDIRECT_URL本身的信息安全都無法保障了，那該如何防止？
這又回到了很早以前我曾討論過的如何防止應用被破解的問題上，應用的身份如何防止被冒名頂替？最簡便且理論安全的方法就是通過簽名對比認證。而這正是新浪微博SSO2.0所采用的方式。
在新浪微博開放平臺網站后臺，對第三方應用綁定包名和簽名。這樣當非信任應用采用信任應用的CONSUMER_KEY和REDIRECT_URL進行認證請求時，由于包名和簽名對應不上，服務器和微博客戶端就會拒絕認證通過，從而補上了SSO1.0的安全缺陷問題。
當然，SSO2.0也不是絕對安全的，它也存在自身的薄弱環節。不過，這就不是本文的討論范圍了。