SAML漏洞的示例分析

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

本文僅限技術研究與討論，嚴禁用于非法用途，否則產生的一切后果自行承擔。

前言

在一次Web應用測試過程中，我在該應用的SAML（安全聲明標記語言）實現中發現了一個安全漏洞。該應用在實現其SAML功能時，采用了不安全的實踐方法，再加上其本身的自定義認證機制也存在安全問題，因此導致了該漏洞的存在。

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

應用程序概述

我們所測試的這個Web應用程序的客戶端允許用戶創建簡單的Web頁面以及Web表格。客戶不僅可以使用這款應用程序來收集終端用戶的信息，而且還可以作為托管人力資源檔案以及其他潛在敏感材料的門戶站點。與此同時，用戶可以通過各種方式來保護這些資料的安全。比如說，他們可以為頁面設置密碼保護，這些頁面將只允許授權用戶訪問。而且，該應用程序還支持使用SAML來實現單點登錄（SSO，即用戶只需要登錄一次就可以訪問所有相互信任的應用系統）。因此，測試這些認證機制就顯得至關重要了，因為安全配置的實現是比較繁瑣且復雜的，很多組織都無法正確地處理這些配置。

驗證功能

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

https://clientwebsite.com/samlpage

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

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

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

至此，基礎功能一切正常。

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

在對SP和IDP之間的SAML流量進行了分析之后，我發現在SP將用戶重定向至IDP以實現身份驗證時，GET參數中包含了一個SAML聲明參數，另一個參數為RelayState。

這個RelayState參數包含了一個客戶端應用程序內的頁面URL地址。解碼之后的地址如下：

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

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

SAML響應會被發送給/sso/saml/acs/73頁面，用戶會被重定向至/samlpage受保護頁面。

查看Burp日志后，你會發現SAML響應又以明文的形式發送了一遍。這一次請求是為了受保護的資源而發送的，它的作用跟RelayState參數類似。之前的URL為：

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

但這一次的URL如下：

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

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

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

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

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

我修改為了：

https://anitianwebsite.com/owned

將請求轉發給IDP后，瀏覽器會加載登錄頁面，使用已知有效賬號登錄后，IDP會將我重定向至SP。攔截請求后，我發現其中的RelayState參數仍然包含的是我修改后的值。客戶端應用仍然能夠認證SAML請求的有效性，并將我重定向至受保護的頁面。而我能夠重定向這個URL，這也就意味著，這里存在一個開放重定向漏洞：

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

而且更可怕的是，saml_token也發送到了我的Web服務器上：

這下這個漏洞就更加嚴重了，因為作為訪問受保護頁面的關鍵，我拿到了saml_token，我就再也不需要用戶密碼或SAML響應了，我只需要用它就可以訪問任意受保護頁面了。

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