前言

目前，很多的系統(tǒng)在登錄的時候都支持通過第三方賬號登錄，如通過微信，qq，微博掃描登錄。這種一般都是通過OAuth2.0搭建完成的。

有一個問題需要思考：通過第三方應(yīng)用登錄的過程是否存在一些安全問題？

本篇文章就來看看OAuth2.0的登錄原理以及可能存在的安全問題。

OAuth2.0登錄原理

Oauth2.0具有多種授權(quán)許可機(jī)制協(xié)議：授權(quán)碼許可機(jī)制、客戶端憑據(jù)機(jī)制、資源擁有者憑據(jù)機(jī)制（密碼模式）和隱式許可機(jī)制。

在了解授權(quán)許可機(jī)制協(xié)議之前，我們得需要了解在OAuth 2.0 的體系里面有 4 種角色，按照官方的稱呼它們分別是資源擁有者、客戶端、授權(quán)服務(wù)和受保護(hù)資源。

資源擁有者（可以指擁有資源的用戶）

客戶端（可以理解為第三方系統(tǒng)/軟件）

授權(quán)服務(wù)（權(quán)限校驗和授權(quán)系統(tǒng)(認(rèn)證服務(wù)中心)）

受保護(hù)資源（用戶在系統(tǒng)上所具有的資源/或者能夠訪問的資源）

授權(quán)碼許可機(jī)制

授權(quán)碼許可機(jī)制的參與者：資源擁有者、客戶端、授權(quán)服務(wù)、受保護(hù)資源

授權(quán)碼模式這種場景下的授權(quán)，第三方軟件可以通過拿到資源擁有者授權(quán)后的授權(quán)碼，以及注冊時的 client_id 和 client_secret 來換回訪問令牌 token 的值。

時序圖

?

下面以一個網(wǎng)站來看一下具體流程

1）打開網(wǎng)站，選擇使用微信登錄頁面

發(fā)送了下面的請求

每個參數(shù)的含義如下

• appid：客戶端應(yīng)用程序的唯一標(biāo)識符的強制參數(shù)，此值是在客戶端應(yīng)用程序向OAuth服務(wù)注冊時生成的。此值唯一，表示來自于那個客戶端。

用微信掃描登錄時需要再微信開放平臺（https://open.weixin.qq.com/）進(jìn)行注冊，注冊完成以后可以拿到AppID和AppSecret兩個。

• redirect_uri：向客戶端應(yīng)用程序發(fā)送授權(quán)代碼時用戶瀏覽器應(yīng)重定向到的URI，這也被稱為"回調(diào)URI"或回調(diào)端點"。在微信開放平臺填寫。
• response_type：確定客戶端應(yīng)用程序期望的響應(yīng)類型以及它想要啟動的流，對于授權(quán)代碼授予類型，值應(yīng)為代碼
• scope：用于指定客戶端應(yīng)用程序要訪問用戶數(shù)據(jù)的哪個子集，這些可能是由OAuth提供程序設(shè)置的自定義作用域，也可能是由OpenIDConnect規(guī)范定義的標(biāo)準(zhǔn)化作用域
• state：用于存儲與客戶端應(yīng)用程序上的當(dāng)前會話綁定的唯一、不可更改的值，OAuth服務(wù)應(yīng)該在響應(yīng)中返回這個確切的值以及授權(quán)代碼，通過確保對其/callback端點的請求來自發(fā)起OAuth流的同一個人，此參數(shù)可作為客戶端應(yīng)用程序的CSRF令牌形式

這里面可能存在的問題：

• 沒有state參數(shù)，可能造成什么危害
• redirect_uri是否可以偽造

2）跳轉(zhuǎn)到授權(quán)頁面，用戶手機(jī)上掃描二維碼

3）手機(jī)上確認(rèn)以后，會返回一個授權(quán)碼（問題：掃描后看是否需要人工確認(rèn)）

返回授權(quán)碼

4）返回授權(quán)碼以后，前端攜帶這個授權(quán)碼到后端，后端就可以與微信端進(jìn)行交互獲取運行的數(shù)據(jù)

資源擁有者憑據(jù)機(jī)制（密碼模式）

資源擁有者憑據(jù)，顧名思義就是資源擁有者的憑據(jù)（賬號，密碼）。在這場景里面就不存在第三方軟件這概念，相當(dāng)于就是訪問系統(tǒng)中的一個子系統(tǒng)，他們之間互相信任。舉個例子來說就是，騰訊有許多的游戲，你只需要用qq賬號密碼就可以登錄游戲玩，不需要進(jìn)行騰訊授權(quán)。因為該游戲是騰訊旗下的，他們相互信任的，所以不存在第三方的說法。

客戶端憑據(jù)機(jī)制的參與者：資源擁有者、客戶端、授權(quán)服務(wù)、受保護(hù)資源

時序圖

客戶端憑據(jù)機(jī)制

相當(dāng)于就是第三方軟件訪問不需要資源擁有者授權(quán)的資源和數(shù)據(jù)，換句話說在這里客戶端也可以看作是資源擁有者。舉個例子來說就是第三方軟件訪問一些公共的服務(wù)，譬如說一些地圖信息，logo圖標(biāo)等。

這種場景下的授權(quán)，便是客戶端憑據(jù)許可，第三方軟件可以直接使用注冊時的 client_id 和 client_secret 來換回訪問令牌 token 的值。

客戶端憑據(jù)機(jī)制的參與者：客戶端、授權(quán)服務(wù)、受保護(hù)資源

時序圖

隱式許可機(jī)制

隱式許可機(jī)制的場景適用于沒有后端服務(wù)的應(yīng)用，舉個例子來說的話就是在瀏覽器中執(zhí)行，譬如說JavaScript應(yīng)用。

在這種情況下，第三方軟件對于瀏覽器就沒有任何保密的數(shù)據(jù)可以隱藏了，也不再需要應(yīng)用密鑰 app_secret 的值了，也不用再通過授權(quán)碼 code 來換取訪問令牌 access_token 的值了。因此，隱式許可授權(quán)流程的安全性會降低很多。

這種場景下的授權(quán)，第三方軟件可以直接使用注冊時的 client_id來換回訪問令牌 token 的值。

時序圖

隱式授權(quán)類型要簡單得多?？蛻舳藨?yīng)用程序無需先獲取授權(quán)碼，然后再將其換成訪問令牌，而是在用戶同意后立即收到訪問令牌。

您可能想知道為什么客戶端應(yīng)用程序并不總是使用隱式授權(quán)類型。答案相對簡單 - 它的安全性要低得多。使用隱式授權(quán)類型時，所有通信都通過瀏覽器重定向進(jìn)行 - 沒有像授權(quán)代碼流中那樣的安全反向通道。這意味著敏感的訪問令牌和用戶數(shù)據(jù)更容易受到潛在攻擊。

OAuth 2.0的安全性考慮

1）重定向URI的安全性

重定向URI是客戶端接收授權(quán)碼和訪問令牌的地址。為了防止攻擊者攔截這些敏感信息，重定向URI應(yīng)該使用HTTPS協(xié)議。此外，授權(quán)服務(wù)器應(yīng)該只接受預(yù)先注冊的重定向URI，以防止攻擊者將用戶重定向到惡意網(wǎng)站。

2）訪問令牌的保護(hù)

訪問令牌是一個敏感的憑證，如果被攻擊者獲取，他們就可以訪問用戶的資源。因此，訪問令牌應(yīng)該在所有傳輸過程中使用HTTPS協(xié)議進(jìn)行加密，防止被竊聽。在存儲訪問令牌時，也應(yīng)該使用適當(dāng)?shù)募用艽胧┻M(jìn)行保護(hù)。

3）刷新令牌的使用和保護(hù)

刷新令牌通常有較長的有效期，甚至可以設(shè)置為永不過期。因此，如果刷新令牌被攻擊者獲取，他們就可以持續(xù)訪問用戶的資源。為了防止這種情況，刷新令牌應(yīng)該只在后端服務(wù)中使用，不應(yīng)該暴露給前端應(yīng)用。此外，刷新令牌也應(yīng)該在所有傳輸和存儲過程中進(jìn)行加密保護(hù)。

4）CSRF攻擊和防范

CSRF（跨站請求偽造）是一種常見的網(wǎng)絡(luò)攻擊，攻擊者通過偽造用戶的請求來執(zhí)行未經(jīng)授權(quán)的操作。為了防止CSRF攻擊，OAuth 2.0的授權(quán)請求可以包含一個state參數(shù)，這是一個隨機(jī)生成的字符串，用于在授權(quán)服務(wù)器重定向回客戶端時驗證請求的合法性?？蛻舳嗽诎l(fā)送授權(quán)請求時生成state參數(shù)，并在接收授權(quán)響應(yīng)時驗證它，如果不匹配，就拒絕響應(yīng)。

OAuth常見漏洞

上面介紹了OAuth常見的一些模式，下面我們來分析一下，OAuth可能存在的問題。

1）CSRF攻擊

該攻擊一般出現(xiàn)的場景一般在登陸以后綁定微信的情況下。應(yīng)用提供了用戶賬號和微信賬號做綁定的功能，也就是說用戶先用自己的賬號登錄，然后可以綁定微信賬號，以便后續(xù)可以使用微信賬號來登錄。

場景一：攻擊者首先通過自己的微信號獲取授權(quán)碼 code，然后偽造一個鏈接誘導(dǎo)受害者登錄以后點擊，那么受害者的賬號就會與攻擊者的微信號進(jìn)行綁定，從而可以登錄受害者的賬號。

這個后果可想而知。那如何避免這種攻擊呢？方法也很簡單，實際上 OAuth 2.0 中也有這樣的建議，就是使用 state 參數(shù)，它是一個隨機(jī)值的參數(shù)。當(dāng)應(yīng)用請求授權(quán)碼的時候附帶一個自己生成 state 參數(shù)值，同時授權(quán)服務(wù)也要按照規(guī)則將這個隨機(jī)的 state 值跟授權(quán)碼 code 一起返回。這樣，當(dāng)應(yīng)用接收到授權(quán)碼的時候，就要在應(yīng)用這一側(cè)做一個 state 參數(shù)值的比對校驗，如果相同就繼續(xù)流程，否則直接拒絕后續(xù)流程。

在這樣的情況下，軟件 A 要想再發(fā)起 CSRF 攻擊，就必須另外構(gòu)造一個 state 值，而這個 state 沒那么容易被偽造。

這本就是一個隨機(jī)的數(shù)值，而且在生成時就遵從了被“猜中”的概率要極小的建議。

2）XSS攻擊

當(dāng)請求抵達(dá)受保護(hù)資源服務(wù)時，系統(tǒng)需要做校驗，比如第三方軟件身份合法性校驗、訪問令牌 access_token 的校驗，如果這些信息都不能被校驗通過，受保護(hù)資源服務(wù)就會返回錯誤的信息。大多數(shù)情況下，受保護(hù)資源都是把輸入的內(nèi)容，比如 app_id invalid、access_token invalid ，再回顯一遍，這時就會被 XSS 攻擊者捕獲到機(jī)會。

試想下，如果攻擊者傳入了一些惡意的、搜集用戶數(shù)據(jù)的 JavaScript 代碼，受保護(hù)資源服務(wù)直接原路返回到用戶的頁面上，那么當(dāng)用戶觸發(fā)到這些代碼的時候就會遭受到攻擊。

因此，受保護(hù)資源服務(wù)就需要對這類 XSS 漏洞做修復(fù)，而具體的修復(fù)方法跟其它網(wǎng)站防御 XSS 類似，最簡單的方法就是對此類非法信息做轉(zhuǎn)義過濾

3）授權(quán)碼失竊

我們知道客戶端在獲取驗證碼后，會調(diào)用回調(diào)地址，然后客戶端服務(wù)器去獲取令牌。那么我們?nèi)绻梢阅玫絼e人的授權(quán)碼，是不是也可以偽造請求直接去獲取令牌了。

攻擊者劫持了授權(quán)碼之后，想要進(jìn)一步獲取令牌，一般還需要請求上下文state：

• 保證授權(quán)碼與請求上下文state一致

攻擊者只要想辦法實現(xiàn)上面兩點，就能輕松獲取令牌了。為了實現(xiàn)這一點，攻擊者攔截用戶授權(quán)請求，并將客戶端重定向uri指向自己的頁面，用戶完成身份認(rèn)證和授權(quán)，如果授權(quán)服務(wù)器使用寬松的redirect_uri校驗，則會驗證通過生成一個授權(quán)碼，然后帶著授權(quán)碼和state信息重定向到攻擊者頁面，攻擊者拿到授權(quán)碼code和state后會偽造用戶向客戶端的請求（調(diào)用客戶端重定向地址），因為state和code都是受害用戶請求的，所以客戶端驗證通過并向授權(quán)服務(wù)器請求令牌，授權(quán)服務(wù)器接收到的請求會被認(rèn)為是正常請求，校驗通過頒發(fā)token，客戶端獲取到token繼續(xù)請求受保護(hù)資源，資源服務(wù)器將返回請求資源，但是接收資源的人不是正常用戶，而是攻擊者！下面看一下這種攻擊的實現(xiàn)流程：

看到這里可能有一個疑問，我們?nèi)绻カ@取授權(quán)code呢？

4）重定向URL被篡改

有的時候，授權(quán)服務(wù)提供方并沒有對第三方軟件的回調(diào) URI 做完整性要求和完整性校驗。

比如，第三軟件 B 的詳細(xì)回調(diào) URI 是https://app.org/callback，那么在完整性校驗缺失的情況下，只要以https://app.org開始或者其他域名的的回調(diào) URI 地址，都會被認(rèn)為是合法的。

那么我們就可以修改回調(diào)地址，然后誘導(dǎo)用戶去點擊這個鏈接，這樣當(dāng)返回code的時候就會去回調(diào)我們修改后的地址，這樣就可以在服務(wù)器上看到其code。進(jìn)而按照授權(quán)碼失竊來進(jìn)行攻擊

問題：大部分的授權(quán)服務(wù)器都限制了url的host頭，如何進(jìn)行利用？

第一種方式：結(jié)合任意url跳轉(zhuǎn)。如果驗證服務(wù)器沒有完全匹配，可以通過../這種方式改變路徑的?？梢栽陧撁嫔险乙粋€任意url跳轉(zhuǎn)漏洞，配合這種漏洞進(jìn)行利用。

如下圖，通過../改變路徑，然后將跳轉(zhuǎn)的url指向我們的服務(wù)器，這樣就可以在服務(wù)器的日志上看到想要的內(nèi)容

第二種方式：尋找可以留言的地方。然后將內(nèi)容發(fā)送留言的內(nèi)容中去獲取

5）登錄流程設(shè)計缺陷

登錄流程如果存在設(shè)計缺陷也可能會導(dǎo)致接管其它人的賬號。如掃描登錄時無需人員確認(rèn)，那么就可以將二維碼發(fā)送給其他人誘導(dǎo)點擊。

portswigger案例

OAuth 隱式流程繞過身份驗證

https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow

使用給的用戶名和密碼登錄

username=wiener&password=peter

這里只校驗了token，然后根據(jù)email判斷登錄用戶，我們替換email重放數(shù)據(jù)包就可以登錄到其它賬號

成功完成

其它的實驗內(nèi)容可以看下面的鏈接

https://xz.aliyun.com/t/13349

總結(jié)

OAuth2.0的漏洞總體上來說就是下面的兩種

1）獲取到授權(quán)code，獲取授權(quán)code的方式就是未驗證回調(diào)url，這種方式比較困難

2）就是綁定微信時利用CSRF漏洞，將攻擊者的微信綁定到受害者的賬號上。這種需要與用戶有交互也比較困難。

一個安全的OAuth2.0認(rèn)證應(yīng)該做到下面的幾點

• 授權(quán)碼使用一次之后將其銷毀
• 授權(quán)服務(wù)器應(yīng)該采用精確匹配的重定向URI校驗算法
• 避免讓授權(quán)服務(wù)器成為開放重定向器，在非法的請求中直接返回錯誤而不是重定向

參考鏈接

https://blog.csdn.net/qq_43284469/article/details/132510807

https://blog.csdn.net/u010020088/article/details/143903471

https://cloud.tencent.com/developer/article/2418791

https://www.cnblogs.com/hellowhy/p/15533625.html

https://xz.aliyun.com/t/13349

閱讀原文：原文鏈接