總算回家了，完全沒想到這次要外出一個月，今天開始恢復更新。

前幾天忘記在哪裡看到了這個write up的中文翻譯了，當時也沒看，今天打算寫總結的時候剛好發現了這篇write-up，決定就是這篇了。

這個在uber發現的漏洞實現上是由logout時重定向引起的反射型XSS，是作者在分析uber的SAML功能時發現的，本來作者是打算做bypass SAML authentication的，但是沒有成功，之後才轉向分析其他可能的漏洞。

什麼是SAML

在說SAML(Security Assertion Markup Language)之前，要先說一下什麼是SSO(Single Sign-On)，SAML是SSO的一種解決方案。

所有使用網際網路的使用者應該都知道登入是怎麼回事，通過註冊並登入一個網站應用，你就可以享受專門針對你個人的網站應用服務了。由於HTTP的無狀態性，為了避免對一個網站應用的多次登入，網站應用會使用session ID(例如cookies)來標識使用者，這樣你只要登入一次該網站應用，在session ID有效期間就不需要再次登入了。但存在一個問題——cookies只在同一個domain下才有效。對於一個大型的網站，它可能有多個應用，而不同應用有不用的domain，這個時候使用cookies就不合適了。

於是就出現了一個解決辦法，網站單獨建立一個身份提供者(Identity Provider)，該應用建立、維護並管理使用者認證，而不同的應用作為服務提供者(Service Provider)，當用戶登入一個應用時，應用會根據使用者的origin將其重定向到身份提供者那裡，身份提供者驗證使用者身份，返回一個響應，告訴服務提供者使用者是否驗證通過，若驗證通過，使用者就可以使用該應用了。提供一個典型的應用場景，開啟淘寶(https://www.taobao.com/)和天貓(https://www.tmall.com/)頁面，這時候兩個都是未登入狀態，如果你這時候登陸淘寶，再重新整理天貓頁面，會發現天貓頁面也是登陸狀態。

實現SSO有多重方式，OpenID、Oauth和SAML等，這裡要說的就是SAML，顧名思義，SAML是一個基於XML的開源標準資料格式，它規定了身份提供者和服務提供者之間交換認證資訊等資料的資料格式，也就是說使用SAML，在應用向身份提供者請求驗證使用者時，兩者之間是通過xml傳遞資訊的。

漏洞發現過程

 在作者對uber的子域名進行掃描收集時，發現很多內部域名都會被重定向到uber.onelogin.com進行身份驗證，onelogin是一個統一訪問管理平臺，提供基於SAML的SSO，而之前在使用SAML的應用中已經存在一些身份認證繞過的漏洞，所以作者嘗試尋找uber中是否存在這些漏洞，但是發現已經有人提交過了。

./dirsearch.py -u https://carbon-prototype.uberinternal.com:443/oidauth/ -ejson

然後

https://carbon-prototype.uberinternal.com:443/oidauth/logout

這個頁面吸引了作者的注意力，因為logout功能通常會伴隨著一個重定向，而這個過程中可能存在XSS漏洞。

開啟上面的頁面，會被重定向到

https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1

注意裡面的base引數，是一個URL，當作者把它修改為javascript:alert(123);後，成功實現了反射型的XSS。

最後作者通過指令碼，找到所有接收SAML響應的網址，然後請求該域名下的oidauth/prompt目錄，看是否存在該反射型XSS漏洞

1. 對一個新的應用進行測試時，可以看是否存在在其他應用中已經發現的漏洞

2. 為什麼會想到目錄掃描：在請求包的資料中發現一個oidauth/目錄

3. logout功能可能存在XSS漏洞，值得進一步測試