• 欢迎访问挑战自我博客网站,安全研究,web渗透,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入挑战自我博客网站 网站主页

实战XSS中遇到的一个过滤绕过

WEB 挑战自我 167次浏览 已收录 0个评论

1、文章背景

出差好几天,今天刚回来,一遍总结这几天的收获,一边把这一周落下的工作补一下。XSS平台回报一个站点有XSS,初步一看没有发现什么新鲜的,感觉随意玩。但是仔细一写POC提交的时候,发现还是了一点点有意识的地方,这边记录一下。

2、文章过程

随着大家的资安意识越来越高,现在好多站点都上了WAF,过滤了一大批像我这类脚本小子~~~~,清楚明白自己的不足,就要下大力气去弥补,真的去做一件事情的话,你会发现,其实也就那样,并没有很高深莫测,这个世间哪有什么天才,都是%1的天赋 + %9的兴趣 + %45的坚持 + %45的思考与总结。

今天这个XSS的挖掘其实是他的过滤机制的一个不足吧,回头我再深入看看。整体过滤原理就还是转码,不是简单的转码,是多次转码。

实例说明,假设测试的payload就是最简单的

<script>xxxx(1111)</script>

先看看,直接输入服务器是什么反应:
实战XSS中遇到的一个过滤绕过

发现中括号被转义成了HTML实体编码了,这样触发不了XSS,接下来,我们对payload进行一次URL编码,编码过后的代码为:

%3c%73%63%72%69%70%74%3e%78%78%78%78%28%31%31%31%31%29%3c%2f%73%63%72%69%70%74%3e

这时候,再带入测试看看效果:
实战XSS中遇到的一个过滤绕过

发现和没有编码的测试效果,完全一样,也就是说这类简单的编码过滤已经被服务器过滤了,一开始我提了一句,今天的实战不是一次编码,是多次编码,那么我们就再来一次全体的URL编码,这次编码过后的payload如下:

%25%33%63%25%37%33%25%36%33%25%37%32%25%36%39%25%37%30%25%37%34%25%33%65%25%37%38%25%37%38%25%37%38%25%37%38%25%32%38%25%33%31%25%33%31%25%33%31%25%33%31%25%32%39%25%33%63%25%32%66%25%37%33%25%36%33%25%37%32%25%36%39%25%37%30%25%37%34%25%33%65

这时候,再带入测试看看效果:
实战XSS中遇到的一个过滤绕过

发现居然没有过滤我们的特殊字符了,接下来就是构造闭合包的问题了,这里我就不再多说了

3、文章总结与提升

3.1、编码字数探究

上面提到了多次编码,那么多少次算是一个合适的方案呢?这个是和站点自身的解码代码有关系的,实战中的这个站点支持三次URL编码,四次就不行了。可以看看我的burp编码图

实战XSS中遇到的一个过滤绕过

3.2、不同编码方式组合探究

以上的编码我都是全部字符进行URL编码,那么如果我分开测试行不行呢?举个例子就是,我先进行一次URL全编码,然后再进行一次URL特殊字符编码,答案也是可以的

<script>xxxx(1111)</script>

进行一次URL全编码如下:
%3c%73%63%72%69%70%74%3e%78%78%78%78%28%31%31%31%31%29%3c%2f%73%63%72%69%70%74%3e

进行一次URL特殊字符编码如下:
%253c%2573%2563%2572%2569%2570%2574%253e%2578%2578%2578%2578%2528%2531%2531%2531%2531%2529%253c%252f%2573%2563%2572%2569%2570%2574%253e

可以发现最后的测试payload中是%253c之类的字符,这样也是可以触发XSS的,大家可以自行测试

4、记录

实战测试记录记录如下,方便自己后续查看。

1、二次URL全编码
2、三次URL全编码
3、一次URL全编码,一次特殊字符URL编码
其他测试自行进行……

挑战自我博客, 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明实战XSS中遇到的一个过滤绕过
喜欢 (6)
支付宝[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址