一次针对存储型XSS的fuzzing

 

前两天朋友扔给我一个XSS让我瞅瞅,当时的我也是懵逼的。当时也就想搞好玩,所以有了下面的分析。

1、添加script代码

XSS这种漏洞,还是找输入输出的地方。最后,我在留言的地方发现可以输入,而且用户自己可以查看内容。一般来讲,用户自己看到的内容和收件人看到的内容是一样的。

随便写了点东西,发现内容输出的位置在标签之间,标签之间的话还是比较好办的。而且,可以添加标签,也就是说,< >的符号没有被过滤。因此我测试如下的payload

 

结果发现,关键字script中间多了一个<x>标签。当我单独输入script的时候却不会触发,然后大小写什么的也测试了,还是不行

2、基于事件属性

既然script标签已经被过滤了,我就html的事件属性来测试一下。刚开始的时候,我就用了一些简单的onerroronclick之类的。结果发现我会的属性都被过滤,至少在这个时候我还没有想到fuzzing

基本可以弄清楚了,遇到<keyword>就在keyword中间添加一个<x>

3、基于伪协议

可以用的伪协议有javascriptDATA URI,以及vbscript

那么我们就会定义一个标签,然后把伪协议内容写在hrefsrclink之类的属性中

 

属性编码,HTML的属性支持实体编码,这种方法很容易绕过黑名单里面的关键字,因此有了下面语句

 

伪协议编码,伪协议的默认编码为US-ASCII,根据MIME协议,支持的编码有base64quoted-pritable7-bit8-bit等等;绕过的方法就很多了,如下

 

 

结果比较有意思的是,这里居然还过滤了,。因此上面的伪协议的方法是不可行的

另外有一点,是关于实体编码的:我采用实体编码之后,html源码显示的属性值就应该是html的实体编码,如下图:

Alt text.1470818893434

但是,在查看目标的输出点的时候,发现输出是:

Alt text.1470818921880

我靠,我说怎么不能触发,实体编码已经被解码过一次了,那么既然这样的话,试一试二次编码???

结果,二次编码之后成了下面的样子,先放一边吧,这个下来再研究了,今天的重点也不在这里

Alt text.1470820188601

4、fuzzing

上面的东西就莫名其妙地就被过滤了,既然它是基于关键字的,关键字那么多它总不能全部过滤了吧?

最后可以用的事件有下面这些:

 

 

既然要做到悄无声息,那么就要选择一个好的事件。对比了一下,oncanplay是比较好用的

Alt text.1470822743456

 

.1470822791735

Alt text

5、参考

DATA URI Scheme

 

此条目发表在黑盒渗透分类目录,贴了, , 标签。将固定链接加入收藏夹。

1 则回应给 一次针对存储型XSS的fuzzing

  1. Pingback引用通告: 一周信息安全干货分享(第72期) – Guge's blog

发表评论

电子邮件地址不会被公开。 必填项已用*标注