安全矩阵

 找回密码
 立即注册
搜索
查看: 2023|回复: 0

实战 | 记一次实战中SelfXSS+CSRF+越权漏洞的组合拳

[复制链接]

65

主题

65

帖子

241

积分

中级会员

Rank: 3Rank: 3

积分
241
发表于 2022-5-8 14:29:51 | 显示全部楼层 |阅读模式
本帖最后由 PEnticE 于 2022-5-8 14:31 编辑

实战 | 记一次实战中SelfXSS+CSRF+越权漏洞的组合拳 (qq.com)
0x01 前言

在渗透测试中,经常能够遇到这样一种XSS漏洞,它通常存在于比较隐私的个人信息配置等等功能中,有一个非常鲜明的特点就是“只有自己可见,别人不可见”,XSS漏洞只能攻击自己自然是毫无价值的,因此此类Self-XSS几乎不会被SRC所接受。本文通过对一个在线游戏平台的测试经历,提供一种攻击思路,把原本无害的Self-XSS漏洞与其它漏洞结合起来打组合拳,从而实现无害漏洞从无害到高危的利用。

0X02 比较有“含金量”的Self-XSS

为什么说这个Self-XSS有含金量,且听我慢慢道来。信息搜集的时候我发现一个游戏玩家中心,用于编辑各种个人信息的。


秉着有框就插并且不影响正常业务的原则,我自然而然的把目光投向了“详细地址”这个输入框(其实是因为真实姓名和联系电话都严格过滤所有特殊符号导致无法XSS),既然是联系方式,想来应该是所有玩家都能看见的吧,如果被我找到XSS,那就是存储型XSS到手了,美滋滋。至少当时我是这么想的。

在这个框里输入test1111,然后在页面源代码中Ctrl+F搜索test1111定位其输出位置。算是找XSS的常规操作吧


看这样子一下就反应过来这玩意是输出在JS代码里,是被<script>标签所包裹的,那简单闭合一下不就完事了,只需要用 ’; 闭合前半部分,再用//注释掉后面的特殊符号,最后在中间填入JS代码,不就完成了吗,构造test11111’;alert(‘1’);// 毫无技术含量可言!

定睛一看,我就知道




没关系没关系,不就是墙吗。我们来FUZZ一下看看它拦什么,试试eval()。


还是寄,这就只能拿出我的压轴绝活了。输出在<script>标签内时,有一种绝活。JS有一个特性是Function()(); 你没看错,大写的Function和小写的function其含义有所不同。

对于Function()来说,写在其第一个括号内的JS语句会被直接执行。比如说我们可以试试

  1. Function(alert(‘1’))();
复制代码




是不是会发现,这个特性的用法和eval();不能说是十分相似吧,至少也可以说是一模一样。

不过360肯定是不允许alert堂而皇之的出现的,有没有办法把它隐藏起来呢。既然都能使用类似eval()的功能了,我们还怕这个?直接使用atob();函数,它的作用是把base64编码后的内容还原,我们直接把alert(1) base64编码一下。


注意,这里有个坑点,这个base64编码后的字符串填入atob中时,必须要去掉最后面的等于号,不然会失效


可以看到还是成功了,说明这个payload是可用的


为了防止360再拦,还是要做的周全一点,还有一个小技巧就是反引号其实可以用于代替括号使用,为了让效果更炸裂一点,我们把alert(1)换成alert(document.cookie)。所以我们最终可以构造这么一个语句


  1. ';Function(atob`YWxlcnQoZG9jdW1lbnQuY29va2llKQ`)();//
复制代码



这时候可以看到已经成功绕过并且成功弹出COOKIE了

能弹COOKIE对于一个在线游戏平台来说肯定是极其危险的,到这里我已经开香槟了。但是万万没想到


啊这,难道是Self-XSS?!我又回去重新看了一下功能,发现这个点别的用户还真就看不到,我去,联系方式不就是给其它用户看的吗,其他用户看不到,你设计这个功能干啥啊!
没招了,只能想想有没有别的办法。

0x02 搞这么多CSRF防御机制,有用?

最最经典的结合Self-XSS漏洞进行攻击的手法就是CSRF,两者结合即可变成XSRF甚至是XSRF蠕虫。它的实现原理基本上是这样的:攻击者构建一个POC.html,它的功能是往用户的页面中嵌入恶意的JS语句,这时候我们就可以脱离存储型和反射型XSS的范畴了。只要诱骗目标访问了我们的CSRF POC,再跳转到上文提到的用户攻击,XSS攻击就完成了。

说干就干,我们看看这个修改个人信息的点会不会有CSRF漏洞

乍一看,这可太吓人了。又有Origin又有Referer,这个CSRF是不是又要裂开了。然而,实战中要绕过这类验证最好的方法就一个字,删!直接把他们的信息删掉看看能不能过,有些粗心的开发者光顾着判断值对不对,却没有考虑值是不是为NULL。


发包成功,看来目标并没有校验Origin和Referer是否为空。那看看我们的信息有没有被修改成功


不就成了,直接用burp造一个CSRF POC出来,把其中的address的值改成XSS语句


登上另一个测试账号的情况下,试试我们的CSRF POC



这个测试账号2也弹窗了捏


这下总算结束了,提交一波。


拳头硬了

0x03 意外收获的平行越权

还得找找有没有别的漏洞来组合着打。看来看去我发现了他们这个类似论坛的网站还有一个评论的功能,不知道这个评论的用户身份是由什么进行控制的。抓个包看看


评论这个行为会调用非常多的接口,故而会产生好几个数据包,我在http history中筛选了一会,突然发现一个数据包不太对劲

这个数据包,它似乎传递的是用户名、uid、sid、用户头像。这个uid就引起了我的注意,你们不会在用uid来表示用户的身份吧。那我改几个试试?



真是太有趣了,既然评论这里在用uid控制,那么刚刚的更改个人信息的功能点,会不会也有类似的接口传递uid控制呢,我马上回去翻了一下http history,终于看到一个数据包也在传递类似的uid




重新登陆后发现email已经修改成功


这就更是一个大洞了,只要我利用这个越权漏洞,放到burp里去批量爆破别人uid,并且把address换成我们刚刚的XSS payload,那么全站用户的个人信息都会被写入恶意JS代码。基本就等于我们直接获取了全站账号的登陆权限,该网站是一个比较大型的在线平台,旗下多个子域名的百度权重都在7以上,该站账号还是比较值钱的。对于一个大型在线平台来说,这无疑是非常致命的一个漏洞。

0x04 结语

本文主要通过一个漏洞挖掘的实战案例来分析了一下实战中遇到Self-XSS该如何设法将其转换为有利用价值的漏洞,属于是帮大伙挖SRC赚钱的一个小TIPS。

其中还提到了一些比较好玩的思路

例如:使用Function()();来替换eval()从而绝杀输出在<script>中的情况、置空Origin和Referer来尝试绕过这种防御CSRF的机制、结合CSRF与XSS进行攻击、结合平行越权与XSS进行攻击。

所以实战中遇到低危漏洞千万不要气馁,一定要想方设法的打组合拳将其危害最大化,还有就是测某个功能点的时候一定要记得看HTTP History,很多功能需要多个接口分多个步骤进行处理才能实现,养成分析HTTP History的习惯可以让你发现许多隐蔽的接口,从而发现更多的漏洞!

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|安全矩阵

GMT+8, 2024-3-29 22:43 , Processed in 0.012702 second(s), 18 queries .

Powered by Discuz! X4.0

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表