OAuth2.0第三方賬號登錄原理及常見漏洞
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
前言目前，很多的系統在登錄的時候都支持通過第三方賬號登錄，如通過微信，qq，微博掃描登錄。這種一般都是通過OAuth2.0搭建完成的。 有一個問題需要思考：通過第三方應用登錄的過程是否存在一些安全問題？ 本篇文章就來看看OAuth2.0的登錄原理以及可能存在的安全問題。 OAuth2.0登錄原理Oauth2.0具有多種授權許可機制協議：授權碼許可機制、客戶端憑據機制、資源擁有者憑據機制（密碼模式）和隱式許可機制。 在了解授權許可機制協議之前，我們得需要了解在OAuth 2.0 的體系里面有 4 種角色，按照官方的稱呼它們分別是資源擁有者、客戶端、授權服務和受保護資源。 資源擁有者（可以指擁有資源的用戶） 客戶端（可以理解為第三方系統/軟件） 授權服務（權限校驗和授權系統(認證服務中心)） 受保護資源（用戶在系統上所具有的資源/或者能夠訪問的資源） 授權碼許可機制授權碼許可機制的參與者：資源擁有者、客戶端、授權服務、受保護資源 授權碼模式這種場景下的授權，第三方軟件可以通過拿到資源擁有者授權后的授權碼，以及注冊時的 client_id 和 client_secret 來換回訪問令牌 token 的值。 時序圖
下面以一個網站來看一下具體流程 1）打開網站，選擇使用微信登錄頁面
發送了下面的請求
每個參數的含義如下
用微信掃描登錄時需要再微信開放平臺（https://open.weixin.qq.com/）進行注冊，注冊完成以后可以拿到AppID和AppSecret兩個。
 這里面可能存在的問題：
2）跳轉到授權頁面，用戶手機上掃描二維碼
3）手機上確認以后，會返回一個授權碼（問題：掃描后看是否需要人工確認）
返回授權碼
4）返回授權碼以后，前端攜帶這個授權碼到后端，后端就可以與微信端進行交互獲取運行的數據
資源擁有者憑據機制（密碼模式）資源擁有者憑據，顧名思義就是資源擁有者的憑據（賬號，密碼）。在這場景里面就不存在第三方軟件這概念，相當于就是訪問系統中的一個子系統，他們之間互相信任。舉個例子來說就是，騰訊有許多的游戲，你只需要用qq賬號密碼就可以登錄游戲玩，不需要進行騰訊授權。因為該游戲是騰訊旗下的，他們相互信任的，所以不存在第三方的說法。 客戶端憑據機制的參與者：資源擁有者、客戶端、授權服務、受保護資源 時序圖
客戶端憑據機制相當于就是第三方軟件訪問不需要資源擁有者授權的資源和數據，換句話說在這里客戶端也可以看作是資源擁有者。舉個例子來說就是第三方軟件訪問一些公共的服務，譬如說一些地圖信息，logo圖標等。 這種場景下的授權，便是客戶端憑據許可，第三方軟件可以直接使用注冊時的 client_id 和 client_secret 來換回訪問令牌 token 的值。 客戶端憑據機制的參與者：客戶端、授權服務、受保護資源 時序圖
隱式許可機制隱式許可機制的場景適用于沒有后端服務的應用，舉個例子來說的話就是在瀏覽器中執行，譬如說JavaScript應用。 在這種情況下，第三方軟件對于瀏覽器就沒有任何保密的數據可以隱藏了，也不再需要應用密鑰 app_secret 的值了，也不用再通過授權碼 code 來換取訪問令牌 access_token 的值了。因此，隱式許可授權流程的安全性會降低很多。 這種場景下的授權，第三方軟件可以直接使用注冊時的 client_id來換回訪問令牌 token 的值。 時序圖
隱式授權類型要簡單得多。客戶端應用程序無需先獲取授權碼，然后再將其換成訪問令牌，而是在用戶同意后立即收到訪問令牌。 您可能想知道為什么客戶端應用程序并不總是使用隱式授權類型。答案相對簡單 - 它的安全性要低得多。使用隱式授權類型時，所有通信都通過瀏覽器重定向進行 - 沒有像授權代碼流中那樣的安全反向通道。這意味著敏感的訪問令牌和用戶數據更容易受到潛在攻擊。 OAuth 2.0的安全性考慮1）重定向URI的安全性重定向URI是客戶端接收授權碼和訪問令牌的地址。為了防止攻擊者攔截這些敏感信息，重定向URI應該使用HTTPS協議。此外，授權服務器應該只接受預先注冊的重定向URI，以防止攻擊者將用戶重定向到惡意網站。 2）訪問令牌的保護訪問令牌是一個敏感的憑證，如果被攻擊者獲取，他們就可以訪問用戶的資源。因此，訪問令牌應該在所有傳輸過程中使用HTTPS協議進行加密，防止被竊聽。在存儲訪問令牌時，也應該使用適當的加密措施進行保護。 3）刷新令牌的使用和保護刷新令牌通常有較長的有效期，甚至可以設置為永不過期。因此，如果刷新令牌被攻擊者獲取，他們就可以持續訪問用戶的資源。為了防止這種情況，刷新令牌應該只在后端服務中使用，不應該暴露給前端應用。此外，刷新令牌也應該在所有傳輸和存儲過程中進行加密保護。 4）CSRF攻擊和防范CSRF（跨站請求偽造）是一種常見的網絡攻擊，攻擊者通過偽造用戶的請求來執行未經授權的操作。為了防止CSRF攻擊，OAuth 2.0的授權請求可以包含一個state參數，這是一個隨機生成的字符串，用于在授權服務器重定向回客戶端時驗證請求的合法性。客戶端在發送授權請求時生成state參數，并在接收授權響應時驗證它，如果不匹配，就拒絕響應。 OAuth常見漏洞上面介紹了OAuth常見的一些模式，下面我們來分析一下，OAuth可能存在的問題。 1）CSRF攻擊該攻擊一般出現的場景一般在登陸以后綁定微信的情況下。應用提供了用戶賬號和微信賬號做綁定的功能，也就是說用戶先用自己的賬號登錄，然后可以綁定微信賬號，以便后續可以使用微信賬號來登錄。 場景一：攻擊者首先通過自己的微信號獲取授權碼 code，然后偽造一個鏈接誘導受害者登錄以后點擊，那么受害者的賬號就會與攻擊者的微信號進行綁定，從而可以登錄受害者的賬號。
這個后果可想而知。那如何避免這種攻擊呢？方法也很簡單，實際上 OAuth 2.0 中也有這樣的建議，就是使用 state 參數，它是一個隨機值的參數。當應用請求授權碼的時候附帶一個自己生成 state 參數值，同時授權服務也要按照規則將這個隨機的 state 值跟授權碼 code 一起返回。這樣，當應用接收到授權碼的時候，就要在應用這一側做一個 state 參數值的比對校驗，如果相同就繼續流程，否則直接拒絕后續流程。 在這樣的情況下，軟件 A 要想再發起 CSRF 攻擊，就必須另外構造一個 state 值，而這個 state 沒那么容易被偽造。 這本就是一個隨機的數值，而且在生成時就遵從了被“猜中”的概率要極小的建議。 2）XSS攻擊當請求抵達受保護資源服務時，系統需要做校驗，比如第三方軟件身份合法性校驗、訪問令牌 access_token 的校驗，如果這些信息都不能被校驗通過，受保護資源服務就會返回錯誤的信息。大多數情況下，受保護資源都是把輸入的內容，比如 app_id invalid、access_token invalid ，再回顯一遍，這時就會被 XSS 攻擊者捕獲到機會。 試想下，如果攻擊者傳入了一些惡意的、搜集用戶數據的 JavaScript 代碼，受保護資源服務直接原路返回到用戶的頁面上，那么當用戶觸發到這些代碼的時候就會遭受到攻擊。 因此，受保護資源服務就需要對這類 XSS 漏洞做修復，而具體的修復方法跟其它網站防御 XSS 類似，最簡單的方法就是對此類非法信息做轉義過濾
3）授權碼失竊我們知道客戶端在獲取驗證碼后，會調用回調地址，然后客戶端服務器去獲取令牌。那么我們如果可以拿到別人的授權碼，是不是也可以偽造請求直接去獲取令牌了。 攻擊者劫持了授權碼之后，想要進一步獲取令牌，一般還需要請求上下文state：
攻擊者只要想辦法實現上面兩點，就能輕松獲取令牌了。為了實現這一點，攻擊者攔截用戶授權請求，并將客戶端重定向uri指向自己的頁面，用戶完成身份認證和授權，如果授權服務器使用寬松的redirect_uri校驗，則會驗證通過生成一個授權碼，然后帶著授權碼和state信息重定向到攻擊者頁面，攻擊者拿到授權碼code和state后會偽造用戶向客戶端的請求（調用客戶端重定向地址），因為state和code都是受害用戶請求的，所以客戶端驗證通過并向授權服務器請求令牌，授權服務器接收到的請求會被認為是正常請求，校驗通過頒發token，客戶端獲取到token繼續請求受保護資源，資源服務器將返回請求資源，但是接收資源的人不是正常用戶，而是攻擊者！下面看一下這種攻擊的實現流程：
看到這里可能有一個疑問，我們如果去獲取授權code呢？ 4）重定向URL被篡改有的時候，授權服務提供方并沒有對第三方軟件的回調 URI 做完整性要求和完整性校驗。 比如，第三軟件 B 的詳細回調 URI 是https://app.org/callback，那么在完整性校驗缺失的情況下，只要以https://app.org開始或者其他域名的的回調 URI 地址，都會被認為是合法的。 那么我們就可以修改回調地址，然后誘導用戶去點擊這個鏈接，這樣當返回code的時候就會去回調我們修改后的地址，這樣就可以在服務器上看到其code。進而按照授權碼失竊來進行攻擊 問題：大部分的授權服務器都限制了url的host頭，如何進行利用？ 第一種方式：結合任意url跳轉。如果驗證服務器沒有完全匹配，可以通過../這種方式改變路徑的。可以在頁面上找一個任意url跳轉漏洞，配合這種漏洞進行利用。 如下圖，通過../改變路徑，然后將跳轉的url指向我們的服務器，這樣就可以在服務器的日志上看到想要的內容
第二種方式：尋找可以留言的地方。然后將內容發送留言的內容中去獲取
5）登錄流程設計缺陷登錄流程如果存在設計缺陷也可能會導致接管其它人的賬號。如掃描登錄時無需人員確認，那么就可以將二維碼發送給其他人誘導點擊。 portswigger案例OAuth 隱式流程繞過身份驗證 https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow 使用給的用戶名和密碼登錄 username=wiener&password=peter
這里只校驗了token，然后根據email判斷登錄用戶，我們替換email重放數據包就可以登錄到其它賬號
成功完成
其它的實驗內容可以看下面的鏈接 https://xz.aliyun.com/t/13349 總結OAuth2.0的漏洞總體上來說就是下面的兩種 1）獲取到授權code，獲取授權code的方式就是未驗證回調url，這種方式比較困難 2）就是綁定微信時利用CSRF漏洞，將攻擊者的微信綁定到受害者的賬號上。這種需要與用戶有交互也比較困難。 一個安全的OAuth2.0認證應該做到下面的幾點
參考鏈接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 閱讀原文：原文鏈接 該文章在 2025/5/14 9:24:58 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
?
