我是如何挖掘Uber的XSS漏洞並繞過CSP的
原文： ofollow,noindex">https://medium.com/@efkan162/how-i-xssed-uber-and-bypassed-csp-9ae52404f4c5
前奏
我曾經在Uber的子域上尋找過開放式重定向漏洞，雖然他們並不把“Open Redirect”當作漏洞，但我想“為什麼不把它與其他漏洞聯合起來？也許可能導致帳戶接管或其他什麼威脅呢？”在這種想法的激勵下，我幹勁十足。在partners.uber.com上尋找相關端點時，下面這個URL引起了我的興趣：
https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/
這個URL是在一個論壇中看到的，之後，藉助Google Dork搜尋語法，我又找到了一個類似的URL。那麼，它是否含有開放式重定向漏洞呢？是的！接下來，還有一項工作要做：在登入介面尋找另一個漏洞，以便將兩種組合起來使用。為此，我鼓搗了好幾個小時，不幸的是，官方認為這並沒有報告的必要，按照他們的說法：
“對於開放式重定向漏洞，99％的情況下影響都不大。不過，對於影響較大的那些罕見情況，例如竊取oauth令牌，還是具有提交價值的。”
一週後，我再次檢查了這個URL，發現它已經無法正常工作了，就像現在一樣，無論你輸入什麼http引數，它都會將你重定向到 https://www.wireless.att.com 。
由此來看，他們已經修復好了，問題是，這是他們自己發現的，還是有人報告的呢？我不知道，也不在乎。不過，最初我可是奔著一個大目標去的，最終卻敗興而歸，心裡確實有點不爽。好在哥是個樂天派，沒過多久我的鬥志很快又燃燒起來了，於是決定再次搞點事情，這次要搞的是XSS，而不是自我陶醉！
漏洞分析
如果我問你“在Uber的連結中，最知名的URL是什麼”，你的答案可能是邀請連結。這些連結幾乎無處不在，例如，論壇帖子、Twitter、Facebook、Instagram ......
邀請連結具有不同的URL：
https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我在其中檢測XSS漏洞，但毫無發現:(
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
這個怎麼樣？ 它有相同的邀請程式碼，如果點選它，它將重定向到其他URL，但為什麼不檢查其他引數呢？
在基本的Google Dork搜尋語法的幫助下，我開始對這個子域進行全面的搜尋。
site:partners.uber.com
利用上面的搜素語句，可以找到一個非常龐大的邀請連結列表。我的目標是尋找其他引數，並且真的找到了一個！
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1
看起來的確很酷，但XSS在哪裡呢？ “v”引數顯示的是他/她作為Uber司機工作了多少年，看起來有點像週年慶典。發現這個引數後，我就試圖注入一些XSS有效載荷，但沒有出現XSS彈窗，於是我查看了一下相關的原始碼。
原始程式碼：
content=”static/images/milestones/anniversary/anniversary_1.png” />
注入有效載荷後：
content=”static/images/milestones/anniversary/anniversary_1 “><img src=x onerror=alert(document.cookie)>.png” />
正如您所看到的，這裡並沒有過濾措施，但同時也沒有彈出XSS視窗，這就是說，我們需要考察相關的內容安全策略。什麼是CSP？正如Netsparker的部落格所說：
“內容安全策略(CSP)標準是一種有選擇地指定應該在web應用程式中載入哪些內容的方法。這可以通過使用隨機數或雜湊值將特定域名列入白名單來實現。”
因此，只要有列入白名單的域名，我們就可以嘗試使用它們來對抗CSP。請找到Uber針對partner.uber.com域名的CSP頭部，它太長了，為了保持版面簡潔，這裡只給出“script-src”之後的部分
script-src ‘self’ ‘unsafe-inline’ ‘nonce-9f4b94bf-a195–4d8c-b474–879ae6d1d471’ ‘self’ ‘unsafe-inline’ https://pullo.uberinternal.com https://apis.google.com https://www.google.com https://d1a3f4spazzrp4.cloudfront.net https://*.uber.com https://rules.quantcount.com https://www.google-analytics.com https://ssl.google-analytics.com https://d3i4yxtzktqr9n.cloudfront.net https://d1a3f4spazzrp4.cloudfront.net;
首先，我檢查了rules.quantcount.com並找到了json端點，但沒有太多關於它的資訊。對我們來說，這裡有一個巨大的優勢，因為它們將* uber.com列入了白名單，所以，如果我們能找到任何帶有回撥或任何類似功能的JSON端點，我們就能夠發動XSS攻擊。與此同時，我還拜讀過一個名為“DOM XSS - auth.uber.com”的部落格，博主“stamone”活不錯，讀者不妨讀一讀！
http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html
看看他的文章，他也繞過了CSP，怎麼樣？ 在他的報告中，CSP允許他從* .marketo.com提取一些東東。
實際上，他也是藉助了一些基本的Google Dork搜尋語法，並找到了一個回撥引數，正如您看到的那樣，效果的確不錯。
看完這篇文章後，我訪問了Virustotal網站，並檢查了Uber的子域名，其中一個引起了我的注意！ 什麼，mkto？ “mkto”是marketo的簡稱嗎？
是的！的確如此。
導航至mkto.uber.com的時候，它會將我們重定向到
https://app-ab19.marketo.com/index.php
這絕對就是marketo。所以，接下來我們就可以用它來對抗CSP了。利用一個簡單的有效載荷，我建立瞭如下所示的連結，一旦訪問該連線，就會出現盼望已久的彈窗。
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1"><script src=”https://mkto.uber.com/index.php/form/getKnownLead?callback=alert(document.domain);"></script>
這次，我觸發的是XSS漏洞！
時間線
[03-08-2018]向優步提交漏洞報告
[07-08-2018]將狀態改為“Triaged”
[22-08-2018]傳送並詢問有關流程的其他資訊
[23-08-2018]優步的回覆：“謝謝@mefkan！我們已將該資訊傳遞給內部團隊。”
[27-08-2018]漏洞已修復
[30-08-2018] 獎勵2,000美元
[03-04-2018]有限披露給Hackerone
小結
1 - 千萬不要說“這是一個非常有名的URL，別指望在這裡找到漏洞”。我可以保證，如果這麼想的話，肯定會錯過很多漏洞。
2 - 經常閱讀其他人的文章，特別是正在尋找一些特別的或詳細的資訊的時候。不妨多花些時間用於閱讀和理解文章背後的邏輯。
3 - 永不放棄，努力努力再努力，最終就會如願以償。