OAuth 安全指南

from:http://www.oauthsecurity.com/

0x00 前言

---

這篇文章講了OAuth 和 OpenID容易出現漏洞的一些地方。不管是程式設計師還是駭客，閱讀它都會對你大有裨益。

就OAuth本身而言有一套很嚴謹的結構，但是很多開發者在部署AOuth的時候因為疏忽產生很多安全隱患，這些隱患如果被攻擊者利用，是很難防禦的。

現在很多大網站，都存在OAuth安全隱患，我寫這篇文章的原因也是希望大家意識到由OAuth配置不當所引發的安全問題，和警示開發人員要小心處理關於OAuth的問題。

這篇文章並沒有闡釋OAuth的具體工作流程，想了解的話可以看他們的官網。

此文建議配合另外一個文章來看，包括烏雲上很多實際案例：《OAuth 2.0安全案例回顧》

0x01 Authorization Code flow

---

1. 透過繫結攻擊者的賬號進行賬戶劫持

這是一種比較常見的攻擊手法，其實就是一種CSRF攻擊。

平臺返回code到事先設定好的回撥url，SITE/oauth/callback?code=CODE，之後客戶端把code連同client credentials 和 redirect_uri一起提交換取access_token。

如果客戶端沒有部署 state這個引數來防止CSRF攻擊，那麼我們就可以透過CSRF輕易地把我們提供的賬號和受害者的賬號繫結。

如下圖所示，很多網站都提供使用社交賬戶登入的功能。

防範方法：在把使用者的資料提交給提供者網站的時候，附帶一個隨機數，在連線返回時，沿著這個隨機數是否改變。

State fixation bug:(state可變漏洞)：在omniauth中一些遺留程式碼會導致state被修改，它使用 /connect?state=user_supplied代替了隨機數。 一些開發者把state拿來做其他的用途，導致他失去了防止CSRF的功能，一個工整的解決方式可以用JSON Web Token as state。

2. 使用會話固化攻擊進行賬戶劫持

在會話固化攻擊中，攻擊者會初始化一個合法的會話，然後誘使使用者在這個會話上完成後續操作，從而達到攻擊的目的。

如果我們訪問一個使用者繫結的連結，比如/user/auth/facebook，這個連結通常會返回 一個附帶使用者資訊的url，其中uid代表了攻擊者的id最終這個id將和受害者使用者繫結。

修復: 確認每一條繫結社交使用者的連結都擁有合法的csrf_token,最好使用post代替get。

Facebook駁回了這個CSRF漏洞的修復建議，很多庫中仍包含這一漏洞。所以不要奢望平臺方總是能給與你可靠的資料。

3. 透過authorization code洩露來劫持資料

OAuth 的文件清楚的寫出了，平臺方應該檢查redirect_uri是否被篡改。但我們通常懶得去檢查它。

這使得很多平臺方在這裡產生了安全隱患，Foursquare (reported), VK (report, in Russian), Github (could be used to leak tokens to private repos)

攻擊的方式很簡單，尋找一個XSS漏洞，搞糟一個連結把redirect_uri修改為你自己的地址。當受害者訪問這個連結時，就會把leaking_page?code=CODE傳送到你的指定地址。

這樣你就可以使用這個洩露的授權碼，在真實的redirect_uri上面登入受害者的使用者了。

修復方法：可變的redirect_uri的確會產生風險，如果你非要用它，在access_token建立的時候驗證它是否被篡改。

0x02 Implicit flow

---

1. redirect可控引起的access_token/signed_request洩露

這個漏洞被媒體稱之為"covert redirect" ，但是這並不是一個新的漏洞。

利用它的前提是需要有一個可以修改的redirect，之後吧response_type替換為token或者是signed_request。302重定向會附帶#後的資訊，而攻擊者只需要透過js擷取即可。

修補方式：在app setting中建立redirect_uri白名單。

2. 透過收集使用者access_token進行賬戶劫持

這個漏洞也被稱為 One Token to Rule Them All.它通常發生在，手機和客戶端app上。

當使用者吧一個ring提交到一個他想登陸的網站時，一個惡意的網站管理員就可以透過這個ring登陸這個使用者正在使用的其他網站。

修補方式：在接受使用者提交的access_token之前，檢查他是否符合client_id。

0x03 Extra

---

1. client credentials 洩露

client credentials其實並沒有那麼重要，你所能做的就是取得auth code，然後手動得到一個access_token。

使用靜態redirect_uri，可以防止這種安全隱患。

2. 會話固化攻擊 (OAuth1.0)

OAuth1.0和OAuth2.0的主要區別就是向平臺傳輸引數的方式不同。在1.0中，客戶把所有引數傳遞給平臺，然後直接得到access_token。所以你可以誘使使用者訪問provider?request_token=TOKEN在授權完成後使用者會被重定向到client/callback?request_token=SAME_TOKEN如果這個TOKEN是我們事先生成的，那麼我們就可以複用這個TOKEN.

這不是一個服務端的bug，通常它被用來釣魚，比如這個案例(FYI, Paypal express checkout has this bug)

3. 中繼平臺

有些平臺本身在其他平臺獲取賬號，同時也為其他使用者提供服務。通常他們都需要將url重定向到第三方網站，token在這樣的鏈條中很容易洩露

Facebook -> Middleware Provider -> Client's callback

而且這個問題基本無法修復。

facebook的解決方法是在callback url後面加上#= 防止其夾帶資料。

4. 繞過redirect_uri認證的一些技巧

如果允許設定子目錄，下面是一些目錄遍歷的技巧

/old/path/../../new/path
/old/path/%2e%2e/%2e%2e/new/path
/old/path/%252e%252e/%252e%252e/new/path
/new/path///../../old/path/
/old/path/.%0a./.%0d./new/path (For Rails, because it strips \n\d\0)

5. 重放攻擊

code經過get傳輸的時候會存在於log檔案中，平臺應該在使用或者過期之後刪除它們。