旋风小黄瓜

2017-07-31 22:37

xss漏洞挖掘思路

本文作者:IMWeb 旋风小黄瓜 原文出处:IMWeb社区 未经同意,禁止转载

前言

xss作为江湖上一种常见的攻击手段,一直有广泛的使用。然而怎么样发现一个交互的地方是否会有xss漏洞呢?有一些通用的思路。一下就是思路的总结。

攻击代码

首先,找到一个你觉得可能会有问题的地方。然后提交这一段代码,如果出现了弹窗,或者打开开发者,发现报了错。那么恭喜你~找到一个xss漏洞啦。

payload分析

上面的那段代码,刚拿来看的时候,可能会恨疑惑这是些什么东西。这是因为,这一长串代码讲所有可能的场景都包含在内了。首先,我们并不知道我们提交之后,服务器返回的response会出现在什么地方。一般来说,会出现在一下几个地方:

  1. html标签之间 -》</防过滤/div id='body' >[输出]< /防过滤/ /div>
  2. html标签之内 -》</防过滤/input type=”text” value=”[输出]” />
  3. 成为javascript代码-》</防过滤/script>a=”[输出]”;...<//script>
  4. 成为css代码-》</防过滤/style>body{font-size:[输出]px;...}<//style>

如果输出结果在标签之间

场景1

</防过滤/div id='body' >[输出]< /防过滤/ /div>
如果我们输入 , 那么标签就会成为 ,攻击成功~

场景2

如果是什么</防过滤/title></ /防过滤/title>< /防过滤/textarea></ /防过滤/textarea> 那么输入,输出的结果就会变成

如果输出的结果在标签之内

场景1

如果输出的地方是这样的:</防过滤/input type=”text” value=”[输出] ” /> 那么我们有两种策略
一种是:
那么输出之后,就会变成

另一种策略是

输出之后的结果就会变成

这两种都可以达到同样的效果。前者是定义一个事件,然后在事件里面执行我们的攻击代码,另一种思路是直接闭合标签,然后插入<//script>直接执行。第一种方法可能看着很麻烦,需要移动才能触发,为啥不直接用第二种呢?但是其实第一种更好。因为<//script>标签很可能被过滤掉,第一种的成功率高一些。

场景2

输出的位置是</防过滤/input type=”hidden” value=”[输出]” /> 在这种情况下,由于设置了hidden,on事件不起作用了,所以我们只能暴力关闭标签。

场景3

输出的位置是</防过滤/input value=”[输出]” type=”hidden” />,
和上面的场景仅仅属性的顺序不同而已。怎么此案能出现高成功率的payload呢?我们可以插入 。 输出之后变成:

这个时候的输出不再是一个隐藏的表单项,而是一个标准的输入框,这个时候移动鼠标,就会触发xss啦。

场景4

如果输出在src/href/action等属性内部,比如< //a href=”[输出]”>click me</ //a>: 我们的payload可以像下面这个样子
前提是我们提交的payload必须出现在这些属性值的开头部分(data协议必须作为整个属性值出现)。对于第一个伪协议,所有的浏览器都支持,不过有一些差异。对于第二个data协议,对于IE不支持。另外,我们提交的这两个payload是可以进行一些混淆的,这样可以更好的绕过过滤机制。
看javascrip/防过滤/:alert(1)这个payload的场景,如果输出一下语句,那么点击后会正常触发。

场景5

如果输出在on事件中。根据不同的场景,我们需要弄清楚我们的输出是整个on事件值出现,还是以某个函数的参数值出现,这个函数是什么等。不同的出现场景可能需要不同的闭合策略。最终目标都是让我们的脚本都能顺利执行。 最神奇的是。那么只要提交alert(1),就可以执行。

成为javascript代码

和场景5类似,有些js代码是服务端输出的,有时会将用户提交的值作为js代码的一部分输出,如以下场景
在这个场景中,我们的payload可以是
他会优先寻找最近的一个script标签闭合,无论这个script标签出现在哪里,都会导致payload成功。

成为css代码

输出如果出现在style属性内。对IE来说,style属性中只要能注入expression关键词,并进行适当的闭合,我们就可以认为目标存在XSS。 比如注入
那么可以得到

1条评论

    您需要 注册 一个IMWeb账号或者 才能进行评论。