基于Cookie的XSS开发之旅 | 从100美元到2300美元

很长一段时间以来，我一直热衷于从HackerOne平台上的漏洞悬赏项目中寻找各类漏洞，每天都会花一定的时间来研究我最喜欢和新出现的项目。我曾无数次偶然发现一个基于cookie的XSS漏洞，这也是我之所以写这篇文章的原因。当cookie中的值直接反映到页面上而无任何过滤时，就会出现这种漏洞。

在一般的情况下，如果我们不能证明这些XSS对他人有危害，就会被认为是self-XSS，这样很可能就得不到审核人员的认可，更别说拿到赏金。因此，在这篇文章中，我将展示如何挖掘出一个得到认可的基于cookie的XSS漏洞。

为了能用恶意的javascript进行攻击，我们需要找到一种方法来设置cookie，并要将受害者引诱到使用了cookie值的页面。综上所述，我们可能会用到以下方法:

1.CRLF注入。当目标站点没有对用户输入的换行符进行过滤拦截时，就会出现此漏洞。我可以往响应中注入一个Set-cookie头，其中包含所需的cookie参数名和对应的值。因此，一旦受害者点击我制作的恶意url，他的浏览器便会保存我所制作的cookie。

现实案例：twitter曾存在类似漏洞（Slippery CRLF injection），利用url如下：https://twitter.com/login?redirect_after_login=/jjjkkk嘊嘍Set-Cookie:jjjjj=a;domain=twitter.com

如果想了解更多关于这类漏洞的报告，可以点击这里。

2.子域上的XSS漏洞。这个XSS必须可以公开访问到，一般来说位于*.vulnerabledomain.com。对于很多漏洞悬赏项目来说，并不是所有的子域都在测试范围内。即使你发现了相关漏洞，要么审核人员根本不接受，要么接受了但没有赏金。在这种情况下，你不应该退缩，这些XSS有可能能帮助我们通过document.cookie功能设置或删除cookie。

可信度不同：相比jira.vulnerabledomain.com/plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com这类带有很长后缀的子域链接，受害者通常更信任主域。特别是如果子域与个人帐户或授权没有关联的话，则更是如此。因此，我们可以使用一个重定向功能来从主域重定向到子域https://vulnerabledomain.com/login?redirectUrl=https://jira.vulnerabledomain.com/path。

此时，如果受害者已有一个session，则重定向很快自动完成；但是如果没有，有可能需要授权。

当用户点击如上链接，cookie将会被子域的XSS重新设置。然后，它再把用户导航到存在基于cookie的XSS的站点页面，再次触发XSS攻击，捕获CSRF令牌乃至更改帐户绑定的电子邮件！

一旦电子邮件地址被更改为我所掌握的，且不存在其他认证手段，那么我就可以更改账户密码，接管帐户。

3.查看是否存在可手动设置cookie的网页，你可以使用dirb、dirserach之类的工具。如果开发人员忘记删除某些敏感页面，则让我们有机可乘。

最近我就在某个网站上发现了一个servlet测试页面，我可以在这个页面上设置具有任意参数名和值的cookie。当然，如果目标站点缺乏对CSRF的防御，那么我们就可以利用其去更改受害者浏览器中的cookie。

这个漏洞可以代替CRLF注入的方案来更改受害者cookie，我最终得到了150美元的奖励，开发人员仍然认为这是一个危险性较低的漏洞。

4.中间人攻击(MITM)。只有当cookie上没有secure flag时，才能使用此方法。如果你不知道这个flag是什么，可以查看OWASP London 2017的“Cookie安全性”研究，https://www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf?source=post_page---------------------------

为了成功攻击，受害者必须和攻击者处于同一网络，否则会影响dns解析。为了验证漏洞存在，你必须:

1)设置如下内容的index.php文件:

<?php if ($_SERVER[‘HTTP_HOST’] == ‘non-existed-subdomain.vulnerabledomain.com’) { setrawcookie(“VID”,’\’+alert(123123123)+\’’, time()+36000, “/”, “.vulnerabledomain.com”,0,1); } ?>

2)在/etc/hosts文件中添加以下数据:127.0.0.1 non-existed-subdomain.vulnerabledomain.com

3)一旦受害者访问non-exild-subdomain.vulnerabledomain.com，就会被修改cookie。e.mail.ru的中间人攻击就是一个实际案例——https://hackerone.com/reports/312548——但是，如你所见，中间人攻击的利用条件较为苛刻，因此由它衍生出的其他攻击很可能并不会被审核人员认同。

案例

在一次挖掘某个网站的漏洞时，我曾发现我的cookie值出现在站点的一个子目录中。然后，我立马检查了<>是否被过滤，并在发现被过滤后使用-alert(document.domain)-实现了XSS攻击。

因为开发人员没有设置cookie的secure flag，因此我们可以用它配合中间人攻击。我的报告如下

随后HackerOne的审核人员明确表示，这是self-XSS，我应该更加努力：

在这之后，我开始仔细检查这个网站，试图找到CRLF注入或XSS来证明它的危险性。

我借助一个很大的域名字典，在暴力破解以及SSL证书的帮助下尽可能多地寻找子域名。

而在这整个过程中，我也发现了其他漏洞，很多不安全地重定向和大量的访问控制缺陷，甚至直接导致厂商将某个子域下线。以上这些为我带来了5000美元的奖励，也许在以后我会和大家分享这些漏洞。

一周后，我总结了一下所有的发现，发现了某个子域的/verification端点，起初我不太重视它，但在草草检查后还是发现了一个/verification/login。

在我点击这个url后，跳转到了/verification/login/?redirect_uri=https://vulnerabledomain.com，在我登录后，该页面迅速重定向到https://vulnerabledomain.com。

在经过反复尝试后，我成功绕过了这个重定向的安全保护vulnerabledomain.com@anotherdomain.com。接着我试图将这个漏洞升级到XSS，其中javascript:alert(1)失败。但是javascript://https://vulnerabledomain.com/%250A1alert(1):0成功，因为存在https://vulnerabledomain，这个payload最终绕过了白名单验证。

然后我立即和前面所述的基于cookie的XSS结合起来。在javascript:https://vulnerabledomain.com/%0A1?document%2ecookie%20%3d%20%27SID%3d137gf6g67f76fg6766123%5c%27-alert%28document%2edomain%29-%5c%27%3b%20expires%3dFri%2c%203%20Aug%202019%2020%3a47%3a11%20UTC%3b%20path%3d%2f%3b%20domain%3d%2evulnerabledomain%2ecom%3b%27%3a0的帮助下，通过子域往cookie中插入payload，然后再自动跳转到主站的那个子页面，最终出现了令人惊喜的报警窗口！双XSS利用成功！我很快更新了安全报告，等待安全人员的回复。

很快，在同一天，我的漏洞得到了审核人员的认可，得到了1000美元的奖励！

而那个基于DOM的XSS（跳转处的XSS），我也得到了200美元的奖励。

最终结果：$1000+$1000+$200(OR)+$100(OR)=$2300

这个漏洞悬赏项目已经存在了一年多，但在不到一个月的时间内我就排到了第一。这个项目已经成为我最喜欢的项目之一，我希望你也能如此！而且，这个项目帮我大大提升了声望排名，在90天的声望排行榜上获得了36这个名次，现在我已收到很多私人漏洞悬赏项目的邀请。

总结

基于cookie的XSS是可以被深度利用，拿到高赏金的。同时也别只看新上架的项目，任何项目都有你还未发现的漏洞，而坚持不懈，永远是挖漏洞的不二法门。

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://medium.com/@iSecMax/%D1%81ookie-based-xss-exploitation-2300-bug-bounty-story-9bc532ffa564