大家好！在開(kāi)始正式的內(nèi)容之前，請(qǐng)?jiān)试S我做個(gè)簡(jiǎn)單的自我介紹。首先，我要說(shuō)明的是我不是什么安全研究人員/安全工程師，確切的來(lái)說(shuō)我是一名安全的愛(ài)好者，這始于兩年前的Uber。我喜歡接觸新的事物，并且每天都在努力提高自己。我也很樂(lè)意與分享我學(xué)到的東西（每周都會(huì)更新哦），因?yàn)槲掖_信“分享即是關(guān)懷”。雖然，現(xiàn)在在賞金計(jì)劃中我已不是新人了，但在安全面前我永遠(yuǎn)是新手。好了，話(huà)不多說(shuō)讓我們步入正題吧！
背景
這次，我打算在Uber的子域上挖掘一些“開(kāi)放重定向”漏洞。雖然，我知道Uber并不將“開(kāi)放重定向（Open Redirect）”視為漏洞。但我想，如果將它與其它漏洞聯(lián)系起來(lái)，也許能導(dǎo)致帳戶(hù)接管或其它什么更嚴(yán)重的安全問(wèn)題呢？我立刻將想法付諸于了行動(dòng)。當(dāng)我在partners.uber.com上尋找端點(diǎn)時(shí)，以下URL引起了我的注意：
https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/
這個(gè)URL是我在一個(gè)論壇中看到的，之后我使用Google dorks也找到了一個(gè)類(lèi)似的URL。那么，它是否受開(kāi)放重定向漏洞的影響呢？答案是肯定的！接下來(lái)我要做的就是，在登錄部分找到一個(gè)漏洞來(lái)組合利用它們。但很不幸，我找了很長(zhǎng)的一段時(shí)間都沒(méi)有任何的發(fā)現(xiàn)。對(duì)于開(kāi)放重定向的問(wèn)題Uber方面回應(yīng)如下：
“99％的開(kāi)放重定向具有低安全性影響， 對(duì)于影響較大的罕見(jiàn)情況，例如竊取oauth令牌，我們?nèi)韵Ｍ茉僖?jiàn)到它們。”
一周后當(dāng)我再次檢查了這個(gè)URL時(shí)我發(fā)現(xiàn)，它已無(wú)法正常工作。就像現(xiàn)在一樣，無(wú)論你輸入什么http參數(shù)，它都會(huì)將你重定向到https://www.wireless.att.com
so，他們修好了吧。是他們自己發(fā)現(xiàn)的還是有人報(bào)告的？我不知道，也不想知道。這讓我感到非常的沮喪，但我很快從沮喪當(dāng)中走了出來(lái)。既然這個(gè)點(diǎn)被堵死了，那讓我們來(lái)找找XSS。
如果我問(wèn)你“Uber的哪個(gè)URL你最眼熟”，你的答案可能是邀請(qǐng)鏈接。你可以在任何地方看到這些鏈接，例如論壇帖子，Twitter，F(xiàn)acebook，Instagram等。
以下是一個(gè)邀請(qǐng)鏈接：
https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我嘗試檢查了XSS，但并沒(méi)有成功:(
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
上面這個(gè)鏈接具有相同的邀請(qǐng)碼，如果你點(diǎn)擊它它將重定向到其他URL，但這里它為什么不檢查其他參數(shù)呢？我決定再次使用dorks進(jìn)行搜索。
site:partners.uber.com
通過(guò)dorks搜索我找到了一個(gè)數(shù)量龐大的邀請(qǐng)鏈接列表。我要做的就是找到另一個(gè)參數(shù)，很幸運(yùn)我找到了一個(gè)！
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1
看起來(lái)很酷，但XSS在哪里呢？“v”參數(shù)顯示的是他/她作為優(yōu)步司機(jī)工作的年限。我嘗試在這個(gè)參數(shù)注入一些XSS payload，但并沒(méi)有XSS彈窗，接著我檢查了源碼。
原始代碼：
content=”static/images/milestones/anniversary/anniversary_1.png” />
注入payload后：
content=”static/images/milestones/anniversary/anniversary_1 “>.png” />
正如你所看到的，我們的payload并未被過(guò)濾，但同時(shí)也沒(méi)有發(fā)生XSS彈窗。根據(jù)我以往的經(jīng)驗(yàn)，這種情況是因?yàn)閱⒂昧藘?nèi)容安全策略（CSP）。什么是CSP？ 正如Netsparker博客當(dāng)中所描述的那樣：
內(nèi)容安全策略（CSP）標(biāo)準(zhǔn)，是一種有選擇地指定應(yīng)在Web應(yīng)用程序中加載哪些內(nèi)容的方法。這可以通過(guò)使用隨機(jī)數(shù)或散列將特定來(lái)源列入白名單來(lái)完成“。
因此，只要找到處在白名單之中的域，我們就可以繞過(guò)CSP。我們來(lái)檢查下Uber的partner.uber.com的CSP標(biāo)頭。這里的內(nèi)容有點(diǎn)長(zhǎng)，因此我只向大家展示了“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端點(diǎn)，但沒(méi)有太多關(guān)于它的信息。但他們將* uber.com的域名均列為了白名單，因此只要我們能夠找到任何帶有回調(diào)或類(lèi)似內(nèi)容的JSON端點(diǎn)，那么我們就能夠執(zhí)行XSS。這里我推薦大家一個(gè)名為“DOM XSS — auth.uber.com”的博客，大家有空可以去翻翻他的文章：
http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html
在他的這篇文章中他成功繞過(guò)了CSP，并且CSP允許他從* .marketo.com獲得一些他想要的東西。
| 
