OAuth實現(xiàn)機制中的常見安全問題有哪些

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

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

快速了解。

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

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

其中有幾個關鍵的要素內(nèi)容需要明白：

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

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

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

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

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

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

授權(quán)類型（response_type）：表示授權(quán)類型，此例中為"code"授權(quán)碼類型；

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

重定向URI（redirect_uri）：表示重定向URI，即授權(quán)成功后要跳轉(zhuǎn)到的地址；

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

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

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

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

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

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

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

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

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

3、之后會跳出一個授權(quán)同意頁面：

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

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

5、https://yourtweetreader.com利用該code，結(jié)合client_id和client_secret，向Twitter資源服務器發(fā)起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上的發(fā)貼內(nèi)容了。

漏洞眾測過程中會發(fā)現(xiàn)的OAuth問題

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

重定向url的錯誤配置

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

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

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

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

則可以有以下幾種redirect_uri規(guī)則繞過技巧：

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

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

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

4、通過構(gòu)造請求鏈接，用referer header實現(xiàn)HTML注入和token竊取：

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

state參數(shù)的錯誤處理

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

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

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

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

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

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

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

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

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

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

認證流參數(shù)信息泄露

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

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

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

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