我之前曾试图在Uber的子域上探求一些开放式重定向漏洞，虽然我知道Uber官方并不把“Open Redirect”认为是一个漏洞，但是我想“为什么不把它与其他漏洞结合起来呢？也容许能会导致帐户接管什么的？”这种想法瞬间激发起了我的兴趣。当我在partners.uber.com上探求干系端点时，以下这个URL引起了我的把稳：
hxxps://partners.uber.com/carrier-discounts/att/redirect?href=hxxp://www.wireless.att.com/
这个URL是我在一个论坛上看到的，在Google Dork的帮助下，我又创造了另一个类似的URL。它是否包含开放式重定向漏洞呢？答案是肯定的。接下来，有一项事情是我必须要做的——在登录界面探求另一个漏洞，来与它进行结合利用。我为此耗费了好几个小时的韶光，不幸的是，Uber官方认为我的创造并没有报告的必要，按照他们的说法：
“99％的开放式重定向都只具有较低的安全性影响。当然，对付影响较大的罕见情形，例如盗取oauth令牌，我们仍旧希望理解它们。”
一周之后，当我再次检讨这个URL时，创造它已经被进行了处理——无论你输入什么http参数，它都会将你重定向到hxxps://www.wireless.att.com。因此，看来Uber官方已经把它修复好了。而这一次，我决定深挖Uber的XSS漏洞。
如果我问你“在Uber的链接中，最有名的URL是什么？”，你的答案很可能是约请链接。由于，这些链接险些无处不在，例如论坛帖子、Twitter、Facebook、Instagram 等等。
约请链接具有不同的URL：
hxxps://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我试图在这个URL中找到XSS漏洞，但终极什么也没有创造。
hxxps://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
这个怎么样呢？ 它具有相同的约请代码，如果你点击它，可以看到它将重定向到其他URL，但为什么不检讨其他参数呢？
在Google Dork的帮助下，我开始对这个子域进行全面的搜索。
site:partners.uber.com
利用上面的这个搜素语句，你可以找到一个非常弘大的约请链接列表。我的目标是探求其他参数，而我的确找到了一个。
hxxps://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）。什么是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’ hxxps://pullo.uberinternal.com hxxps://apis.google.com hxxps://www.google.com hxxps://d1a3f4spazzrp4.cloudfront.net hxxps://.uber.com hxxps://rules.quantcount.com hxxps://www.google-analytics.com hxxps://ssl.google-analytics.com hxxps://d3i4yxtzktqr9n.cloudfront.net hxxps://d1a3f4spazzrp4.cloudfront.net;
首先，我检讨了rules.quantcount.com并找到了json端点，但没有太多关于它的信息。对我们来说，这里有一个巨大的上风，由于它们将 uber.com列入了白名单，以是如果我们能找到任何带有回调或任何类似功能的JSON端点，那么我们就能够实行XSS攻击。
这里有一篇文章（hxxp://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html）给了我灵感，这个名为“stamone”的博主也绕过了CSP。在他的报告中，CSP许可他从 .marketo.com提取一些东西。
实际上，他也是通过利用一些基本的Google Dork搜索语法找到了一个回调参数。正如你所看到的那样，效果非常不错。
看完这篇文章之后，我访问了Virustotal，并检讨了Uber的子域名，个中一个子域名引起了我的把稳。mkto？ 它是marketo的简称吗？
是的！
的确如此。
导航至mkto.uber.com的时候，它会将你重定向到“hxxps://app-ab19.marketo.com/index.php”。
因此，mkto指的绝对便是marketo。以是，现在是时候用它来绕过CSP了。利用一个基本的有效载荷，我创建了以下这个链接。是的，问题办理了。访问这个链接，就会看到之前没有涌现的弹窗。
hxxps://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1\"大众><script src=”hxxps://mkto.uber.com/index.php/form/getKnownLead?callback=alert(document.domain);\公众></script>
好了，到这里，我便触发了XSS漏洞。
以上内容翻译自medium.com的一篇博文，Uber官方已经在上个月27日对这个漏洞进行了修复，而漏洞的提交者也因此得到了2000美元的褒奖。
本文由 黑客视界 综合网络整理，图片源自网络；转载请注明“转自黑客视界”，并附上链接。
