Spring Security OAuth 2.3 Open Redirection漏洞的實例分析

Spring Security OAuth 2.3 Open Redirection漏洞的實例分析，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

在cve上的spring相關漏洞列表里，一眼就看到了這個漏洞——Spring Security OAuth 2.3 Open Redirection(CVE-2019–3778)，既然如此湊巧，那博主就決定研究一下，網上搜了一下，具體的分析沒找到（可能是姿勢不對），就想著自己寫一篇留作記錄。

漏洞篇

漏洞描述

惡意攻擊者可以構造一個請求，發送給使用“授權碼“類型授權的終點上，并且通過“redirect_uri”參數控制跳轉的URI。這可以導致授權服務器將資源所有者用戶代理重定向到被攻擊者控制的URI，從而泄漏授權碼。鑒于oauth3協議的特殊認證機制，該漏洞定位到Medium。

影響產品

Spring Security OAuth 2.3 to 2.3.4

Spring Security OAuth 2.2 to 2.2.3

Spring Security OAuth 2.1 to 2.1.3

Spring Security OAuth 2.0 to 2.0.16

Older unsupported versions are also affected

Spring Security OAuth 簡介篇：

什么是 oAuth？

oAuth 協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是 oAuth 的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此 oAuth 是安全的。

什么是 Spring Security？

Spring Security 是一個安全框架，前身是 Acegi Security，能夠為 Spring 企業應用系統提供聲明式的安全訪問控制。Spring Security 基于 Servlet 過濾器、IoC 和 AOP，為 Web 請求和方法調用提供身份確認和授權處理，避免了代碼耦合，減少了大量重復代碼工作。

oAuth的使用場景

oAuth協議的授權模式

oAuth3.0標準中客戶端必須得到用戶的授權（authorization grant），才能獲得令牌（access token）。oAuth 2.0 定義了四種授權方式：

簡化模式

簡化模式適用于純靜態頁面應用。所謂純靜態頁面應用，也就是應用沒有在服務器上執行代碼的權限（通常是把代碼托管在別人的服務器上），只有前端 JS 代碼的控制權。

授權碼模式

授權碼模式適用于有自己的服務器的應用，它是一個一次性的臨時憑證，用來換取 access_token 和 refresh_token。認證服務器提供了一個類似這樣的接口：

https://www.funtl.com/exchange?code=&client_id=&client_secret=

密碼模式

密碼模式中，用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向 "服務商提供商" 索要授權。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。這通常用在用戶對客戶端高度信任的情況下，比如客戶端是操作系統的一部分。

客戶端模式

如果信任關系再進一步，或者調用者是一個后端的模塊，沒有用戶界面的時候，可以使用客戶端模式。鑒權服務器直接對客戶端進行身份驗證，驗證通過后，返回 token。

Oauth的授權流程如下：

復現篇

1.限制條件

有問題的Spring Security OAuth3版本

oAuth認證使用授權碼模式

用戶需要在登錄的情況下

2.搭建靶機

（靶機自建 ），設置兩個應用程序（客戶端和認證服務器），啟用oauth3做登錄認證。相關資料

https://github.com/spring-projects/spring-security-oauth/releases

https://github.com/oktadeveloper/okta-spring-boot-authz-server-example

靶機如下：

3.靶機使用oauth的版本（存在漏洞的版本）

4.檢查漏洞代碼

代碼中obtainMatchingRedirect方法在檢查參數的時候存在問題

包：org.springframework.security.oauth3.provider.endpoint

類：DefaultRedirectResolver

方法：obtainMatchingRedirect

5.測試內容

用戶登錄后，CLIENT APP執行的以下請求包含REDIRECT_URI參數。只需添加一個百分號即可觸發重定向bypass認證機制

5.1 源請求包含了有效的URI如下：

5.2 攻擊者通過修改redirect_uri參數為http://www.baidu.com 并發送請求，oAuth捕捉到了認證參數有問題，返回結果如下

5.3 此時在修改的 redirect_uri 中加上“%”，再次發送，如下：

5.4 此刻認證被繞過，用戶被重定向了，返回結果如下：

修復：

2.3.xusers should upgrade to2.3.5

2.2.xusers should upgrade to2.2.4

2.1.xusers should upgrade to2.1.4

2.0.xusers should upgrade to2.0.17

Older versions should upgrade to a supported branch

問題的關鍵點在于obtainMatchingRedirect方法在獲取到用戶輸入redirect_url參數時對參數對校驗機制不夠嚴謹，未對“%”這類的特殊字符進行處理，最終導致此類bypass認證的出現。所以，建議各位大牛在自己實現oauth協議的時候，對于接收到的來自用戶的參數多加檢查，最后送大家一句話：Never believe users ！！！

關于Spring Security OAuth 2.3 Open Redirection漏洞的實例分析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。