实战 | 记一次实战中SelfXSS+CSRF+越权漏洞的组合拳
2023-11-7 20:3:51 Author: mp.weixin.qq.com(查看原文) 阅读量:9 收藏

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语句会被直接执行。比如说我们可以试试

Function(alert(‘1’))();

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

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

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

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

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

';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的习惯可以让你发现许多隐蔽的接口,从而发现更多的漏洞!

如果你是一个长期主义者,欢迎加入我的知识星球(优先查看这个链接,里面可能还有优惠券),我们一起往前走,每日都会更新,精细化运营,微信识别二维码付费即可加入,如不满意,72 小时内可在 App 内无条件自助退款

往期回顾

2022年度精选文章

SSRF研究笔记

xss研究笔记

dom-xss精选文章

Nuclei权威指南-如何躺赚

漏洞赏金猎人系列-如何测试设置功能IV

漏洞赏金猎人系列-如何测试注册功能以及相关Tips

福利视频

笔者自己录制的一套php视频教程(适合0基础的),感兴趣的童鞋可以看看,基础视频总共约200多集,目前已经录制完毕,后续还有更多视频出品

https://space.bilibili.com/177546377/channel/seriesdetail?sid=2949374

技术交流

技术交流请加笔者微信:richardo1o1 (暗号:growing)


文章来源: https://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247492508&idx=1&sn=8e1c4e94754f3b948ca490824055e87d&chksm=e8a5e9ffdfd260e91bf170420f2126e80b698859a753c8f21b7f749bc7925ef505e3d8350e89&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh