如何繞過Uber的CSP防御成功XSS，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、重慶小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了南樂免費建站歡迎大家使用！

背景

這次，我打算在Uber的子域上挖掘一些“開放重定向”漏洞。雖然，我知道Uber并不將“開放重定向（Open Redirect）”視為漏洞。但我想，如果將它與其它漏洞聯(lián)系起來，也許能導(dǎo)致帳戶接管或其它什么更嚴(yán)重的安全問題呢？我立刻將想法付諸于了行動。當(dāng)我在partners.uber.com上尋找端點時，以下URL引起了我的注意：

https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/

這個URL是我在一個論壇中看到的，之后我使用Google dorks也找到了一個類似的URL。那么，它是否受開放重定向漏洞的影響呢？答案是肯定的！接下來我要做的就是，在登錄部分找到一個漏洞來組合利用它們。但很不幸，我找了很長的一段時間都沒有任何的發(fā)現(xiàn)。對于開放重定向的問題Uber方面回應(yīng)如下：

 “99％的開放重定向具有低安全性影響， 對于影響較大的罕見情況，例如竊取oauth令牌，我們?nèi)韵Ｍ茉僖姷剿鼈??！?/p>

一周后當(dāng)我再次檢查了這個URL時我發(fā)現(xiàn)，它已無法正常工作。就像現(xiàn)在一樣，無論你輸入什么http參數(shù)，它都會將你重定向到https://www.wireless.att.com

so，他們修好了吧。是他們自己發(fā)現(xiàn)的還是有人報告的？我不知道，也不想知道。這讓我感到非常的沮喪，但我很快從沮喪當(dāng)中走了出來。既然這個點被堵死了，那讓我們來找找XSS。

如果我問你“Uber的哪個URL你最眼熟”，你的答案可能是邀請鏈接。你可以在任何地方看到這些鏈接，例如論壇帖子，Twitter，F(xiàn)acebook，Instagram等。

以下是一個邀請鏈接：

https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue

我嘗試檢查了XSS，但并沒有成功:(

https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue

上面這個鏈接具有相同的邀請碼，如果你點擊它它將重定向到其他URL，但這里它為什么不檢查其他參數(shù)呢？我決定再次使用dorks進(jìn)行搜索。

site:partners.uber.com

通過dorks搜索我找到了一個數(shù)量龐大的邀請鏈接列表。我要做的就是找到另一個參數(shù)，很幸運我找到了一個！

https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1

看起來很酷，但XSS在哪里呢？“v”參數(shù)顯示的是他/她作為優(yōu)步司機工作的年限。我嘗試在這個參數(shù)注入一些XSS payload，但并沒有XSS彈窗，接著我檢查了源碼。

原始代碼：

content=”static/images/milestones/anniversary/anniversary_1.png” />

注入payload后：

content=”static/images/milestones/anniversary/anniversary_1 “>.png” />

正如你所看到的，我們的payload并未被過濾，但同時也沒有發(fā)生XSS彈窗。根據(jù)我以往的經(jīng)驗，這種情況是因為啟用了內(nèi)容安全策略（CSP）。什么是CSP？ 正如Netsparker博客當(dāng)中所描述的那樣：

內(nèi)容安全策略（CSP）標(biāo)準(zhǔn)，是一種有選擇地指定應(yīng)在Web應(yīng)用程序中加載哪些內(nèi)容的方法。這可以通過使用隨機數(shù)或散列將特定來源列入白名單來完成“。

因此，只要找到處在白名單之中的域，我們就可以繞過CSP。我們來檢查下Uber的partner.uber.com的CSP標(biāo)頭。這里的內(nèi)容有點長，因此我只向大家展示了“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端點，但沒有太多關(guān)于它的信息。但他們將* uber.com的域名均列為了白名單，因此只要我們能夠找到任何帶有回調(diào)或類似內(nèi)容的JSON端點，那么我們就能夠執(zhí)行XSS。這里我推薦大家一個名為“DOM XSS?—?auth.uber.com”的博客，大家有空可以去翻翻他的文章：

http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth24.html

在他的這篇文章中他成功繞過了CSP，并且CSP允許他從* .marketo.com獲得一些他想要的東西。

在這當(dāng)中他借助dorks找到了一個回調(diào)參數(shù)，并且你可以看到效果不錯！

看完這篇文章后，我訪問了Virustotal并檢查了Uber的子域。其中一個以mkto開頭的子域引起了我的注意?！癿kto”會是marketo的簡稱嗎？

是的，果然沒錯！

當(dāng)我訪問mkto.uber.com，它將我重定向到了“https://app-ab19.marketo.com/index.php”，這也驗證了我的猜測。現(xiàn)在我們嘗試用它來繞過CSP。我使用payload創(chuàng)建了以下鏈接：

https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1">

可以看到，成功繞過CSP并觸發(fā)了XSS彈窗！

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。