OAuth實現機制中的常見安全問題有哪些

這篇文章給大家介紹OAuth實現機制中的常見安全問題有哪些，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

下面就從安全角度簡要討論OAuth（特別是OAuth 2.0）在實現過程中存在的一些常見問題。

快速了解。

在討論OAuth時，存在幾個不同的版本和授權類型。如果要要閱讀研究，建議你通讀https://oauth.net/2/從中獲得一些基本的知識了解。本文中，我就著重介紹最常見的OAuth 2.0授權碼類型模式（authorization code），它也是授權流程中功能最完整、流程最嚴密的授權模式。本質上來說，OAuth為開發人員提供了一種授權機制，針對當前用戶身份，允許應用程序從另一個應用程序（認證服務器）訪問用戶數據或對用戶帳戶執行某些操作。

比如，網站https://yourtweetreader.com可以為推特用戶提供所有發貼（包括私密發貼）的顯示功能，為了實現該功能，https://yourtweetreader.com需要部署OAuth 2.0機制，它會要求授權訪問用戶推特Twitter的權限以讀取其中的發貼內容，在此之前，https://yourtweetreader.com會跳出一個授權頁面，明確其向用戶Twitter賬戶請求的具體內容。如果用戶點擊同意，https://yourtweetreader.com就會以用戶身份訪問用戶的Twitter賬戶獲取發貼內容，此時，https://yourtweetreader.com獲得的權限是非常高的。

其中有幾個關鍵的要素內容需要明白：

資源所有者（resource owner），也就是擁有應用程序賬號的"用戶"（user）；

資源服務器（resource server），即服務提供商存放用戶生成資源的服務器，或叫應用程序服務器，在此例中即是https://twitter.com。它與下面將要提到的認證服務器（authorization server），可以是同一臺服務器，也可以是不同的服務器；

第三方應用程序（client application）：又稱"客戶端"（client）應用，即此例中的https://yourtweetreader.com，它發起了希望獲得用戶Twitter賬戶權限的授權請求；

認證服務器（authorization server）：認證服務器，即服務提供商專門用來處理認證的服務器，用戶同意第三方應用程序發起的授權請求之后，該服務器會為第三方應用程序生成一個訪問token，即此例中的https://twitter.com；

客戶端ID（client_id）：第三方應用程序為用戶生成的客戶端ID號，通常來說它是一個公開的唯一標識符，第三方應用程序通過client_id來鑒別用戶身份；

第三方應用程序密鑰（client_secret）：這是第三方應用程序發起授權請求時，認證服務器（authorization server）專門為第三方應用程序生成的一個密鑰，它會連同其它認證參數經POST方式發送給認證服務器；

授權類型（response_type）：表示授權類型，此例中為"code"授權碼類型；

權限范圍（scope）：表示第三方應用程序向認證服務器申請的權限范圍；

重定向URI（redirect_uri）：表示重定向URI，即授權成功后要跳轉到的地址；

客戶端的當前狀態（state）：客戶端的當前狀態，可以指定任意值，認證服務器會原封不動地返回這個值。由于它其中可是包含隨機字符或唯一值，所以它的一個重要用處是可以用來當成請求中的CSRF防御手段；

授權模式（grant_type）：表示使用的授權模式，此例中為"authorization_code"；

授權碼（code）：用戶點擊授權同意之后，由認證服務器（authorization server）返回給第三方應用的一個授權碼，之后，第三方應用利用該code結合用戶的client_id和client_secret向認證服務器（authorization server）換取訪問令牌access_token；

訪問令牌（access_token）：第三方應用程序應用該令牌信息代表資源所有者的用戶向資源服務器（resource server）發起請求訪問；

更新令牌（refresh_token）：第三方應用程序在后臺用來獲取下一次的訪問令牌。

有了以上這些入門了解之后，以上述的顯示推特發貼為例，來看看簡單的OAuth流程：

1、用戶訪問https://yourtweetreader.com，點擊“Integrate with Twitter”按鈕；

2、https://yourtweetreader.com向https://twitter.com發起授權請求，希望讀取用戶在Twitter資源服務器（resource server）上的推特發貼；用戶點擊“Integrate with Twitter”按鈕后發生的請求大致如下：

https://twitter.com/auth ?response_type=code &client_id=yourtweetreader_clientId &redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback &scope=readTweets &state=kasodk9d1jd992k9klaskdh223

3、之后會跳出一個授權同意頁面：

4、點擊授權同意后，鏈接會跳轉到上步請求中的redirect_uri部份，并會加上Twitter分配給的code和state參數：

https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh223

5、https://yourtweetreader.com利用該code，結合client_id和client_secret，向Twitter資源服務器發起POST請求，以獲得代表用戶身份的訪問令牌access_token。POST請求大致如下：

POST /oauth/access_tokenHost: twitter.com...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"}

6、最終，上述流程完成之后，https://yourtweetreader.com就會利用獲得的訪問令牌access_token去讀取用戶在Twitter上的發貼內容了。

漏洞眾測過程中會發現的OAuth問題

這里就分享幾類我在漏洞眾測過程中發現的OAuth問題，這些問題將或多或少對OAuth的實現形成安全影響：

重定向url的錯誤配置

這是OAuth實現中的一個常見安全問題，請求中的重定向url（redirect_uri）非常重要，認證服務器（authorization server）返回給第三方應用的授權碼就是附加在該redirect_uri后的，如果該重定向url（redirect_uri）可被配置為其它攻擊者控制的鏈接，那么也就說明攻擊者可以獲取授權碼從而間接劫持用戶賬戶。

該問題可能會存在于多種認證服務器（authorization server）中，有些認證服務器只會接受隸屬第三方應用的url鏈接，而一些則會接受第三方應用的子域名鏈接，或是任何域名鏈接。

按照認證服務器（authorization server）部署的各種重定向url（redirect_uri）規則來看，這里存在幾種redirect_uri規則繞過技巧，假設攻擊者控制的網站為https://evil.com，且redirect_uri存在以下用戶授權請求中：

https://api.twitter.com/oauth3/authorize?client_id=123050457758183&redirect_uri=https://yourtweetreader.com/callback

則可以有以下幾種redirect_uri規則繞過技巧：

1、開放重定向： https://yourtweetreader.com/callback?redirectUrl=https://evil.com

2、路徑遍歷式繞過：https://yourtweetreader.com/callback/../redirect?url=https://evil.com

3、在redirect_uri中構造與第三方應用鏈接相似的域名鏈接：https://yourtweetreader.com.evil.com

4、通過構造請求鏈接，用referer header實現HTML注入和token竊取：

https://yourtweetreader.com/callback/home/attackerimg.jpg

state參數的錯誤處理

這也是OAuth實現中的一個常見安全問題，通常，state參數會被完全忽略或錯誤應用。如果請求中不存在state參數，或是其靜態值總是不變，那么該OAuth流程可能會有跨站請求偽造問題（CSRF）。有時候，即使存在state參數，如果第三方應用不去驗證它，那么也可能會被攻擊者進行利用。假設用戶點擊第三方應用的授權請求之后，資源服務器就會分配給其一個授權碼code，之后該授權碼會連同state參數在第三方應用中執行一個跳轉，如：

https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh223

我曾遇過state參數位置可被構造成另外一個URL來跳轉利用，在redirect_uri形成第一次跳轉后，state參數被攻擊者形成了二次跳轉。而且這種情況會在一些授權登錄場景中出現，可能會導致賬戶劫持。我遇過的例子有：

攻擊者可利用Slack的集成授權功能添加賬戶，間接竊取收信人的信息和相關消息提示；

攻擊者可利用Stripe的集成授權功能重寫覆蓋支付記錄，并竊取受害者賬戶的支付記錄；

攻擊者可利用PayPal的集成授權功能，向受害者賬戶中添加其它綁定賬戶，以此竊取受害者賬戶資金。

用郵箱地址進行“先前賬戶劫持”

另一種OAuth安全問題是，一些第三方應用不僅允許使用“Sign in with X”之類的授權登錄，還允許用戶名密碼登錄，這里就存在兩種可攻擊利用情況：

1、如果第三方應用在用戶賬戶創建（creation）時缺乏郵件驗證，那么攻擊者可以在知曉受害者電郵地址的情況下，在受害者創建該應用賬戶之前，用受害者電郵地址加任意密碼以受害者身份創建該應用賬戶。之后，一旦受害者在第三方應用中嘗試創建或登錄時，由于其電郵地址已被攻擊者先前創建過，因此就會把受害者的創建或登錄流程鏈接綁定到攻擊者之前創建的賬戶中，這就是一種典型的“pre account takeover”（先前賬戶劫持）攻擊，即攻擊者利用受害者信息在受害者創建賬戶之前進行創建，實現賬戶劫持。

2、如果第三方應用在用戶賬戶注冊（sign up）時缺乏郵件驗證，同樣可以利用上述“pre account takeover”方法實現賬戶劫持。

認證流參數信息泄露

對于OAuth的各種認證流參數，嚴格來說，應該區分出哪些是保密且應受到保護的，就比如用戶的client_id和client_secret遭到泄露的話，就非常危險，尤其是client_secret，攻擊者可以利用受信客戶端的實體身份來竊取受害者的訪問令牌access_token和其它隱私信息，甚至實現賬戶劫持。回到我們的上述例子，來看以下過程：

https://yourtweetreader.com應用授權碼、client_id 和 client_secret向資源服務器發起獲取access_token的請求后，利用獲得的access_token將會獲得用戶在資源服務器上的賬戶權限。

如果在客戶端操作過程中client_secret 遭到泄露，那么攻擊者就可能用其來獲取代表受害者用戶身份的access_token，再配合一些社會工程學技巧，攻擊者還可以向OAuth授權添加更多范圍。并且，由于請求來自受信客戶端應用，因此它們都將顯示為合法。

關于OAuth實現機制中的常見安全問題有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。