SAML漏洞的示例分析

這篇文章主要介紹SAML漏洞的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

本文僅限技術(shù)研究與討論，嚴(yán)禁用于非法用途，否則產(chǎn)生的一切后果自行承擔(dān)。

前言

在一次Web應(yīng)用測試過程中，我在該應(yīng)用的SAML（安全聲明標(biāo)記語言）實(shí)現(xiàn)中發(fā)現(xiàn)了一個安全漏洞。該應(yīng)用在實(shí)現(xiàn)其SAML功能時，采用了不安全的實(shí)踐方法，再加上其本身的自定義認(rèn)證機(jī)制也存在安全問題，因此導(dǎo)致了該漏洞的存在。

在這篇文章中，我們將跟大家演示如何利用該這些不安全的配置并結(jié)合有效的釣魚攻擊，來幫助攻擊者遠(yuǎn)程訪問那些可能包含敏感信息的安全頁面。

應(yīng)用程序概述

我們所測試的這個Web應(yīng)用程序的客戶端允許用戶創(chuàng)建簡單的Web頁面以及Web表格?？蛻舨粌H可以使用這款應(yīng)用程序來收集終端用戶的信息，而且還可以作為托管人力資源檔案以及其他潛在敏感材料的門戶站點(diǎn)。與此同時，用戶可以通過各種方式來保護(hù)這些資料的安全。比如說，他們可以為頁面設(shè)置密碼保護(hù)，這些頁面將只允許授權(quán)用戶訪問。而且，該應(yīng)用程序還支持使用SAML來實(shí)現(xiàn)單點(diǎn)登錄（SSO，即用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)）。因此，測試這些認(rèn)證機(jī)制就顯得至關(guān)重要了，因?yàn)榘踩渲玫膶?shí)現(xiàn)是比較繁瑣且復(fù)雜的，很多組織都無法正確地處理這些配置。

驗(yàn)證功能

我使用了一個管理員賬號登錄進(jìn)了應(yīng)用程序，然后創(chuàng)建了一個簡單的頁面。接下來，我添加了以下文本內(nèi)容：“If you can see this，good for you.”。最后，我修改了配置，要求使用SSO認(rèn)證功能。我將該頁面命名為了“samlpage”，然后保存配置，并生成了一個新的URL：

https://clientwebsite.com/samlpage

當(dāng)我嘗試使用未認(rèn)證的瀏覽器會話來加載這個頁面時，我收到了下列信息：

幾秒鐘之后，該頁面重定向到了我們的單點(diǎn)登錄頁面。SAML識別提供商（IDP）為Anitian的SimpleSAMLphp，這里主要用來測試SAML實(shí)現(xiàn)。隨后，Web頁面重定向至了下面這個登錄界面：

如果輸入錯誤的密碼，則無法登錄；如果輸入正確的憑證，我就會被重定向到我們的客戶端應(yīng)用程序。經(jīng)歷了多次重定向之后，我通過了App的認(rèn)證，并成功訪問了受SAML保護(hù)的頁面。

至此，基礎(chǔ)功能一切正常。

接下來，我打算使用BurpSuite的SAMLRaider插件來進(jìn)行測試，該插件可以進(jìn)行一些標(biāo)準(zhǔn)安全測試，比如說簽名修改等等，執(zhí)行起來也很方便。在我的分析過程中，大多數(shù)基礎(chǔ)的SAMLRaider測試都失敗了。但是我發(fā)現(xiàn)，我能夠?qū)DP返回的SAML響應(yīng)重放給客戶端應(yīng)用程序或服務(wù)提供商(SP)。SAML響應(yīng)的有效性按理來說只有因此，也就是一次性的。但是在測試過程中，如果在同一個用戶賬號下使用了多個有效會話，那么同一個SAML響應(yīng)將能夠多次使用。如果攻擊者能夠攔截SAML響應(yīng)，他們就可以打開自己的會話并繞過驗(yàn)證機(jī)制了。這種攻擊跟獲取用戶密碼比較類似，但影響更加嚴(yán)重，因?yàn)楣粽叽藭r將能夠繞過IDP部署的多因素驗(yàn)證機(jī)制。

在對SP和IDP之間的SAML流量進(jìn)行了分析之后，我發(fā)現(xiàn)在SP將用戶重定向至IDP以實(shí)現(xiàn)身份驗(yàn)證時，GET參數(shù)中包含了一個SAML聲明參數(shù)，另一個參數(shù)為RelayState。

這個RelayState參數(shù)包含了一個客戶端應(yīng)用程序內(nèi)的頁面URL地址。解碼之后的地址如下：

https://clientwebsite.com/samlpage?sp_id=73

這個地址就是我創(chuàng)建的保護(hù)頁面地址，但現(xiàn)在它又包含了一個名叫“sp_id”的額外參數(shù)。SP會攜帶它自己的參數(shù)并將該地址發(fā)送給IDP。登錄進(jìn)IDP后，用戶會收到指向SP（我們的客戶端）的重定向請求，IDP會將SAML響應(yīng)轉(zhuǎn)發(fā)給SP并攜帶RelayState參數(shù)，而且這個參數(shù)是無法進(jìn)行修改的，然后原樣返回給SP。

SAML響應(yīng)會被發(fā)送給/sso/saml/acs/73頁面，用戶會被重定向至/samlpage受保護(hù)頁面。

查看Burp日志后，你會發(fā)現(xiàn)SAML響應(yīng)又以明文的形式發(fā)送了一遍。這一次請求是為了受保護(hù)的資源而發(fā)送的，它的作用跟RelayState參數(shù)類似。之前的URL為：

https://clientwebsite.com/samlpage?sp_id=73

但這一次的URL如下：

https://clientwebsite.com/samlpage?saml_token=<reallylong string>

我無法解碼saml_token參數(shù)，但根據(jù)參數(shù)名，我覺得它應(yīng)該挺重要。我猜它應(yīng)該是用來判斷是否允許訪問samlpage頁面的。為了測試，我用未認(rèn)證瀏覽器會話加載了這個地址及saml_token參數(shù)。有趣的是，我竟然直接進(jìn)入了受保護(hù)的頁面，而且沒有重定向至IDP，我也沒有進(jìn)行登錄。如果我有一個有效的saml_token值，我就能訪問并查看受保護(hù)頁面了。

接下來的問題就是，RelayState值的響應(yīng)是什么？如果我能修改參數(shù)值，然后將用戶重定向至任意站點(diǎn)，那么這里就是一個開放重定向漏洞了。

重新進(jìn)行SSO請求后，我攔截了發(fā)送至IDP的原始SAML請求，并修改了RelayState值，我選擇使用了我自己的一臺Web服務(wù)器。原來的URL如下：

https://clientwebsite.com/samlpage?sp_id=73

我修改為了：

https://anitianwebsite.com/owned

將請求轉(zhuǎn)發(fā)給IDP后，瀏覽器會加載登錄頁面，使用已知有效賬號登錄后，IDP會將我重定向至SP。攔截請求后，我發(fā)現(xiàn)其中的RelayState參數(shù)仍然包含的是我修改后的值?？蛻舳藨?yīng)用仍然能夠認(rèn)證SAML請求的有效性，并將我重定向至受保護(hù)的頁面。而我能夠重定向這個URL，這也就意味著，這里存在一個開放重定向漏洞：

https://anitianwebsite.com/owned?saml_token=<longvalue here>

而且更可怕的是，saml_token也發(fā)送到了我的Web服務(wù)器上：

這下這個漏洞就更加嚴(yán)重了，因?yàn)樽鳛樵L問受保護(hù)頁面的關(guān)鍵，我拿到了saml_token，我就再也不需要用戶密碼或SAML響應(yīng)了，我只需要用它就可以訪問任意受保護(hù)頁面了。

以上是“SAML漏洞的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！