
现在已经有一段时间了,我一直在寻找HackerOne平台上的漏洞,并且在主要工作之外分配了一定的时间来检查我最喜欢的程序和新程序。 我无数次遇到了基于cookie的XSS漏洞,它将成为本文的主要特征。 当cookie参数的值反映在页面上时,会发生这种类型的漏洞。 默认情况下,除非我们依次证明其危险,否则它们将被视为自行XSS。 实际上,今天,我将告诉您如何利用基于cookie的XSS漏洞,并且还将通过测试一家公司的例子来说明问题,我总共从中获得了7300美元的研究资金。
为了在用户端执行javascript,您需要找到一种设置cookie的方法,并在必要时将受害者引诱到嵌入cookie的页面。 利用此错误的可能方法:
⠀1
. CRLF注射。 如果没有正确的验证和阻止换行符,则会发生此漏洞。 我们可以使用所需的名称和cookie的值来实现Set-cookie标头,并在浏览器中进行设置。 实际示例:在twitter.com上以重定向方式进行湿润CRLF注入-https://twitter.com/login?redirect_after_login=/jjjkkk喽Set-Cookie:jjjjj = a;域= twitter.com

可以在HackerOne上阅读有关此类漏洞的报告
hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection2.子域上的XSS漏洞。 XSS必须可公开访问并且位于通配符* .vulnerabledomain.com上。 对于许多错误赏金计划,子域不在范围内,也就是说,在大多数情况下,错误要么根本不被接受,要么带有“不符合赏金资格”标记。 在这种情况下,您不应退缩,但为了与基于cookie的XSS连接,您可以将时间花在搜索XSS上以获得奖励。 如果检测到XSS,我们可以使用document.cookie函数设置或删除cookie。
增强影响:通常,受害人甚至比使用jira.vulnerabledomain.com甚至通过URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com都更信任弱势域.com的主域。 。 如果此子域未与个人帐户或授权无关,则更有可能切换到主域而不是子域。 基于上述内容,我们可以使用站点内重定向功能来重定向到
脆弱域.com / login?redirectUrl = https://jira.vulnerabledomain.com/path子域,以获得更好的效果。
如果受害者有一个活动会话,则重定向将是自动的,如果没有,则需要授权。 当用户单击此类链接时,该cookie还将从存在Reflected XSS的子域中安装,并可以进一步向上游发送-使用基于cookie的XSS的页面,在此页面中漏洞利用可以起作用,这反过来又将捕获令牌的CSRF值并完成更改电子邮件地址的请求。 因此,如果没有相关问题(例如,额外确认电子邮件密码或来自旧邮箱的代码的更改),则两个XSS漏洞的组合可能导致帐户被接管。
3.检测允许设置cookie的测试文件。 足以发现内容检测工具(dirb,dirserach等),开始挖掘,如果开发人员忘记执行清理,则可以偶然发现这些文件。
最近,我找到了一个测试servlet html页面,可以在该页面上安装具有任意名称和值的cookie。 当然,缺少对POST请求的保护,因此,如果受害者访问CSRF漏洞(或者您可以将POST更改为GET),则可以在其浏览器中安装cookie。

该错误被视为CRLF注入的替代方案,已通过删除/ examples /进行了修复,并为低严重度错误支付了$ 150。 尽管h1 triager提供了中等级别的功能,但开发人员仍然倾向于认为这是低严重性。
4.中间人攻击(MITM)。 仅当cookie上没有安全标志时,才可以应用此方法。 如果您不知道它是哪种标记,或者只是想刷新内存,我建议您使用OWASP London 2017查看Cookie安全性的演示文稿
www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf 。
为了成功进行攻击,有必要使受害者位于攻击者的网络中,否则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-existed-subdomain.vulnerabledomain.com,然后打开反映Cookie的页面。
https://hackerone.com/reports/312548上e.mail.ru上有一个很好的利用MITM的例子,正如您所看到的,MITM足以证明存在很小的漏洞危险,但是该奖项与“存储的XSS”级别不符,因为仅显示了该奖项。 “本地”操作模式,即不是“荒野”。 如果研究人员花一点时间在* .mail.ru上搜索XSS或CRLF注入(无数),则奖励可能会略有增加。
但是,并非所有的黑客程序都通过MITM接受基于cookie的XSS。 如果范围排除项显示“ Self XSS”,则可以将此操作视为“ Self XSS”并设置信息性或n / a,这并不总是令人满意。 现在,我将讨论在平台的下一次搜寻过程中发生的类似事件。
在测试站点时,我突然发现,经过编辑的cookie的价值反映在站点的子目录之一中。 我做的第一件事是检查字符“ / <>的显示。原来只有字符<>被过滤,这告诉我们不能超出范围,但是很明显其他字符没有被过滤无需三思,我们实现了“ -alert(document.domain)-”并执行了js。
由于开发人员未给cookie提供安全标志,因此在这种情况下,MITM方法有效。 已决定向该计划发送一份报告,具有以下影响:

HackerOne的工作人员(尝试者)明确指出,这是自XSS,我必须更加努力:

之后,我开始在现场冲浪,并尝试找到CRLF注射液或XSS来证明危险。
⠀我必须借助一个大型词典来扩展子域列表,使用SSL证书抓取子域并使用其他技巧。 结果很快就出现了,因为我使用VPS运行了大多数工具。 我报告了一些不时发现的错误,并在必要时从范围外进行了检查。 我遇到了许多Open Redirects甚至是不当访问控制漏洞,价格为5000美元,但我仍然无法捕捉到捆绑软件所必需的漏洞。 上面提到的错误是非常有趣且危险的,报告发布后整个子域都立即脱机了,也许将来如果程序公开,我将在hackerone.com/w2w上打开报告。
一周后,检查了用于检测内容的脚本的结果,找到了端点/验证,起初我并不特别重视它,但仍然在上面设置了脚本-找到了/验证/登录子目录。 转换后,将显示/verification/login/?redirect_uri=https://vulnerabledomain.com页面,该页面在登录后将重定向到redirect_uri值,或者如果存在会话则立即重定向。 飞向入侵者后,发现了一个开放的重定向保护旁路- 试图将错误发布到XSS-javascript:alert(1)有效负载失败,javascript:alert(1)//也是如此。 但是javascript有效负载:// https://vulnerablesite.com/%250A1?警报(1):0次射击,因为由于
弱势网站的存在,该参数通过了白名单验证。

在通过通知窗口疯狂地驱动鼠标之后(我总是这样做),我立即设置为在基于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成功放置在* .vulnerabledomain.com上。 进入带有Cookie的页面后,珍贵的警报开始了! 双XSS,加油! :)我补充了报告并等待答案。

在同一天,“妙招”从三合会飞来了(如果您可以这样称呼),并获得了赏金。 愿上帝保佑那些分流的公司!
对于我安装了cookie的基于DOM的XSS,赏金也到了。

测试结果
$ 1000 + $ 1000 + $ 200(或)+ $ 100(或)=
$ 2300该程序已经运行了一年多,但是在不到一个月的时间里,我就获得了第一名,并进行了相当多的测试-我试图分阶段处理大多数端点,评估它们的反应,了解站点的工作原理,甚至测试了桌面应用程序。 这个漏洞赏金计划已经成为HackerOne上最受欢迎的计划之一。 希望您也有一天能找到相同的一个! :)

另外,正是这个程序给我带来了新的提升(mail.ru-第一个),它使我获得了2500点的声誉(你的连帽衫),并在90天之内获得了排行榜中第36位的声誉,这应该给人以新的认识。 尽管无论排行榜上的存在如何都存在嫁接,但我经常取消旧的嫁接,等待新的接替。
简要简介
- 基于Cookie的XSS可以完全利用。 如果尝试更深入地挖掘,则可以获得赏金而不是n / a,这会破坏信号并降低-5信誉。
- 如果程序较旧,这并不意味着程序中将没有漏洞。 如果果实长时间挂在树上,则低垂度的果实将被立即采摘(子域接管等)。 其他水果继续挂,但更高。 为了获得它们,您需要付出一些努力。
- 有时,最好长期专注于一个程序,找到尽可能多的漏洞并进行监控。 最好找到您喜欢的程序并将其破坏。
- 持久性以及对理解Web应用程序的工作方式以及某些功能及其相互之间的交互的渴望,是成功搜索漏洞赏金中的漏洞的关键。
如果您想了解我的最新文章和新闻,我建议您订阅电报频道/ twitter,可以在下面找到其链接。