我之前曾试图在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美元的奖励。
本文由 黑客视界 综合网络整理，图片源自网络；转载请注明“转自黑客视界”，并附上链接。