我是如何挖掘Uber的XSS漏洞并绕过CSP的

原文： 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 - 永不放弃，努力努力再努力，最终就会如愿以偿。