前言

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

有一個(gè)問題需要思考：通過第三方應(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)限校驗(yà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)碼，以及注冊時(shí)的 client_id 和 client_secret 來換回訪問令牌 token 的值。

時(shí)序圖

?

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

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

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

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

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

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

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

這里面可能存在的問題：

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

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

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

返回授權(quán)碼

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

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

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

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

時(shí)序圖

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

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

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

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

時(shí)序圖

隱式許可機(jī)制

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

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

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

時(shí)序圖

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

您可能想知道為什么客戶端應(yīng)用程序并不總是使用隱式授權(quán)類型。答案相對簡單 - 它的安全性要低得多。使用隱式授權(quán)類型時(shí)，所有通信都通過瀏覽器重定向進(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ù)

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

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

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

4）CSRF攻擊和防范

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

OAuth常見漏洞

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

1）CSRF攻擊

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

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

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

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

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

2）XSS攻擊

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

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

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

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

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

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

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

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

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

4）重定向URL被篡改

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

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

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

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

第一種方式：結(jié)合任意url跳轉(zhuǎn)。如果驗(yàn)證服務(wù)器沒有完全匹配，可以通過../這種方式改變路徑的。可以在頁面上找一個(gè)任意url跳轉(zhuǎn)漏洞，配合這種漏洞進(jìn)行利用。

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

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

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

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

portswigger案例

OAuth 隱式流程繞過身份驗(yàn)證

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

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

username=wiener&password=peter

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

成功完成

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

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

總結(jié)

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

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

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

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

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

參考鏈接

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

閱讀原文：原文鏈接