我是如何绕过Uber的CSP防御成功XSS的？
大家好！在开始正式的内容之前，请允许我做个简单的自我介绍。首先，我要说明的是我不是什么安全研究人员/安全工程师，确切的来说我是一名安全的爱好者，这始于两年前的Uber。我喜欢接触新的事物，并且每天都在努力提高自己。我也很乐意与分享我学到的东西（每周都会更新哦），因为我确信“分享即是关怀”。虽然，现在在赏金计划中我已不是新人了，但在安全面前我永远是新手。好了，话不多说让我们步入正题吧！
背景
这次，我打算在Uber的子域上挖掘一些“开放重定向”漏洞。虽然，我知道Uber并不将“开放重定向（Open Redirect）”视为漏洞。但我想，如果将它与其它漏洞联系起来，也许能导致帐户接管或其它什么更严重的安全问题呢？我立刻将想法付诸于了行动。当我在partners.uber.com上寻找端点时，以下URL引起了我的注意：
https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/
这个URL是我在一个论坛中看到的，之后我使用Google dorks也找到了一个类似的URL。那么，它是否受开放重定向漏洞的影响呢？答案是肯定的！接下来我要做的就是，在登录部分找到一个漏洞来组合利用它们。但很不幸，我找了很长的一段时间都没有任何的发现。对于开放重定向的问题Uber方面回应如下：
“99％的开放重定向具有低安全性影响， 对于影响较大的罕见情况，例如窃取oauth令牌，我们仍希望能再见到它们。”
一周后当我再次检查了这个URL时我发现，它已无法正常工作。就像现在一样，无论你输入什么http参数，它都会将你重定向到https://www.wireless.att.com
so，他们修好了吧。是他们自己发现的还是有人报告的？我不知道，也不想知道。这让我感到非常的沮丧，但我很快从沮丧当中走了出来。既然这个点被堵死了，那让我们来找找XSS。
如果我问你“Uber的哪个URL你最眼熟”，你的答案可能是邀请链接。你可以在任何地方看到这些链接，例如论坛帖子，Twitter，Facebook，Instagram等。
以下是一个邀请链接：
https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我尝试检查了XSS，但并没有成功:(
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
上面这个链接具有相同的邀请码，如果你点击它它将重定向到其他URL，但这里它为什么不检查其他参数呢？我决定再次使用dorks进行搜索。
site:partners.uber.com
通过dorks搜索我找到了一个数量庞大的邀请链接列表。我要做的就是找到另一个参数，很幸运我找到了一个！
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1
看起来很酷，但XSS在哪里呢？“v”参数显示的是他/她作为优步司机工作的年限。我尝试在这个参数注入一些XSS payload，但并没有XSS弹窗，接着我检查了源码。
原始代码：
content=”static/images/milestones/anniversary/anniversary_1.png” />
注入payload后：
content=”static/images/milestones/anniversary/anniversary_1 “>.png” />
正如你所看到的，我们的payload并未被过滤，但同时也没有发生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’ 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”的博客，大家有空可以去翻翻他的文章：
http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html
在他的这篇文章中他成功绕过了CSP，并且CSP允许他从* .marketo.com获得一些他想要的东西。
大家好！在开始正式的内容之前，请允许我做个简单的自我介绍。首先，我要说明的是我不是什么安全研究人员/安全工程师，确切的来说我是一名安全的爱好者，这始于两年前的Uber。我喜欢接触新的事物，并且每天都在努力提高自己。我也很乐意与分享我学到的东西（每周都会更新哦），因为我确信“分享即是关怀”。虽然，现在在赏金计划中我已不是新人了，但在安全面前我永远是新手。好了，话不多说让我们步入正题吧！
背景
这次，我打算在Uber的子域上挖掘一些“开放重定向”漏洞。虽然，我知道Uber并不将“开放重定向（Open Redirect）”视为漏洞。但我想，如果将它与其它漏洞联系起来，也许能导致帐户接管或其它什么更严重的安全问题呢？我立刻将想法付诸于了行动。当我在partners.uber.com上寻找端点时，以下URL引起了我的注意：
https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/
这个URL是我在一个论坛中看到的，之后我使用Google dorks也找到了一个类似的URL。那么，它是否受开放重定向漏洞的影响呢？答案是肯定的！接下来我要做的就是，在登录部分找到一个漏洞来组合利用它们。但很不幸，我找了很长的一段时间都没有任何的发现。对于开放重定向的问题Uber方面回应如下： 本文来自无奈人生安全网
“99％的开放重定向具有低安全性影响， 对于影响较大的罕见情况，例如窃取oauth令牌，我们仍希望能再见到它们。”
一周后当我再次检查了这个URL时我发现，它已无法正常工作。就像现在一样，无论你输入什么http参数，它都会将你重定向到https://www.wireless.att.com
so，他们修好了吧。是他们自己发现的还是有人报告的？我不知道，也不想知道。这让我感到非常的沮丧，但我很快从沮丧当中走了出来。既然这个点被堵死了，那让我们来找找XSS。
如果我问你“Uber的哪个URL你最眼熟”，你的答案可能是邀请链接。你可以在任何地方看到这些链接，例如论坛帖子，Twitter，Facebook，Instagram等。
以下是一个邀请链接：
https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我尝试检查了XSS，但并没有成功:(
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
上面这个链接具有相同的邀请码，如果你点击它它将重定向到其他URL，但这里它为什么不检查其他参数呢？我决定再次使用dorks进行搜索。 无奈人生安全网
site:partners.uber.com
通过dorks搜索我找到了一个数量庞大的邀请链接列表。我要做的就是找到另一个参数，很幸运我找到了一个！
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1
看起来很酷，但XSS在哪里呢？“v”参数显示的是他/她作为优步司机工作的年限。我尝试在这个参数注入一些XSS payload，但并没有XSS弹窗，接着我检查了源码。
原始代码：
content=”static/images/milestones/anniversary/anniversary_1.png” />
注入payload后：
content=”static/images/milestones/anniversary/anniversary_1 “>.png” />
正如你所看到的，我们的payload并未被过滤，但同时也没有发生XSS弹窗。根据我以往的经验，这种情况是因为启用了内容安全策略（CSP）。什么是CSP？ 正如Netsparker博客当中所描述的那样：
www.wnhack.com
内容安全策略（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”的博客，大家有空可以去翻翻他的文章：
http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html
在他的这篇文章中他成功绕过了CSP，并且CSP允许他从* .marketo.com获得一些他想要的东西。
copyright 无奈人生