很长一段时间以来,我一直热衷于从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.com3)一旦受害者访问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。在经过反复尝试后,我成功绕过了这个重定向的安全保护[email protected]。接着我试图将这个漏洞升级到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://nosec.org/home/detail/2793.html原文:https://medium.com/@iSecMax/%D1%81ookie-based-xss-exploitation-2300-bug-bounty-story-9bc532ffa564白帽汇从事信息安全,专注于安全大数据、企业威胁情报。公司产品:FOFA-网络空间安全搜索引擎、FOEYE-网络空间检索系统、NOSEC-安全讯息平台。为您提供:网络空间测绘、企业资产收集、企业威胁情报、应急响应服务。
本文出自快速备案,转载时请注明出处及相应链接。