如何绕过Uber的CSP防御成功实现XSS攻击

41yf1sh 漏洞 2018-09-26 11:35:17

271087

导语：起初，我试图在Uber的子域名上，寻找一些开放式重定向漏洞。尽管我知道，Uber他们没有将开放式重定向问题作为漏洞看待，但我认为，如果存在这一问题，可以与其他漏洞相结合，从而实现帐户越权登陆或者其他漏洞利用方式。

前言

各位“猎人”们，大家好。在我们开始详细分析漏洞之前，首先想对自己做一个简单的介绍。

我并不是安全研究员或安全工程师，我只是一个乐于学习新事物并且每天都在努力提升自己的人。此前，由于上学的原因，我没有机会将自己的发现记录下来，但现在由于我正处于假期，并且我相信分享能带来共赢，因此我决定每周都发布一篇文章。我的安全之旅始于2年前参加的Uber漏洞赏金计划。尽管我在这个漏洞赏金计划中不是新手，但在安全圈里我却是一个彻头彻尾的萌新，因此我的博客可能对于安全专家来说并不是很有趣。不管怎样，让我们开始分析这一漏洞。

起源

起初，我试图在Uber的子域名上，寻找一些开放式重定向漏洞（Open Redirect Vulnerabilities）。尽管我知道，Uber他们没有将开放式重定向问题作为漏洞看待，但我认为，如果存在这一问题，可以与其他漏洞相结合，从而实现帐户越权登陆或者其他漏洞利用方式。我立刻将这一想法付诸了行动。当我在partners.uber.com上寻找突破口时，这个URL引起了我的兴趣：

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

经过验证，这个URL存在开放式重定向的问题。在找到了这个位置之后，我们还必须要寻找到另一个漏洞，并与之组合利用。但随着时间的推移，很多个小时过去了，我还是没能找到其他的漏洞，因此也无法将详情报告给Uber。

针对这一漏洞，Uber方面是这么说的：

针对开放式重定向，99%的漏洞只具有低安全性影响。但对于产生较大影响的高危漏洞，我们还是会接收此类漏洞提交。

一周后，我检查了这个URL，发现该URL已经不存在此前的问题。无论你输入什么HTTP参数，该URL都会重定向到https://www.wireless.att.com。

那么问题来了，究竟是他们自己意识到这个问题，还是有人报告过这一问题呢？我并不知道，但这也不重要。于是，我继续开始探寻Uber存在的其他漏洞，并把重点放在了XSS漏洞上。

漏洞详情

如果我问你，在Uber的所有链接之中，大家最熟悉的链接是什么？你的答案可能会是邀请链接。因为，我们可以在各种地方看到这些链接：论坛帖子、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中使用的是相同的邀请代码。在用户点击后，它将会重定向到其他URL上，然而却没有检查其他参数。

在这个严重问题的帮助下，我开始在这个子域名范围内寻找漏洞。

网站是：partners.uber.com。

通过上面这个问题的帮助，我们找到了一个非常大的邀请链接列表。此时，我认为应该找到另一个参数，随后便发现了一个。

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

这个URL看起来很酷，但XSS在哪里呢？其中，“v”参数表明Uber司机工作了多少年，就像庆祝周年纪念日一样。在我发现这个参数之后，我立即尝试注入一些XSS Payload，但最后XSS没有弹出窗口，于是我查了一下源代码。

原始代码：

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

注入Payload后代码：

content=”static/images/milestones/anniversary/anniversary_1 “><img src=x onerror=alert(document.cookie)>.png” />

正如大家所看到的，没有对其进行过滤，同时也没有XSS弹出窗口。发生这样的情况，首先要考虑内容安全策略（Content Security Policy）。

什么是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列入白名单。因此，如果我们能找到任何带有回调的JSON终端或者相似内容，那么都可以执行XSS。与此同时，我通过阅读Stamone的“DOM XSS — auth.uber.com”博客，学到了不少知识，也推荐给各位读者阅读。

Stamone的报告内容如下：http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html。除此之外，他还成功绕过了CSP。在他的报告中，CSP已经允许他从*.marketo.com获取一些东西。

所以，他使用了基本的dorks，并找到了一个回调参数，在这里效果很好。

在看完这篇文章之后，我立即访问VirusTotal并检查了Uber的子域名，其中有一个域名是mkto，我不禁好奇地问，mkto是Marketo的简称吗？

是的，它是。因此系统会将我们重定向到https://app-ab19.marketo.com/index.php 。这绝对是marketo，但现在用它来对付CSP。借助于基本的Payload，我创建了这个链接，并进行检查，从而确定出这个地方存在问题。

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>