xss漏洞挖掘思路
前言xss作为江湖上一种常见的***手段，一直有广泛的使用。然而怎么样发现一个交互的地方是否会有xss漏洞呢？有一些通用的思路。一下就是思路的总结。***代码
首先，找到一个你觉得可能会有问题的地方。然后提交这一段代码，如果出现了弹窗，或者打开开发者，发现报了错。那么恭喜你~找到一个xss漏洞啦。
payload分析
上面的那段代码，刚拿来看的时候，可能会恨疑惑这是些什么东西。这是因为，这一长串代码讲所有可能的场景都包含在内了。首先，我们并不知道我们提交之后，服务器返回的response会出现在什么地方。一般来说，会出现在一下几个地方：
[*]html标签之间 -》</防过滤/div id='body' >[输出]< /防过滤/ /div>
[*]html标签之内 -》</防过滤/input type=”text” value=”[输出]” />
[*]成为javascript代码-》</防过滤/script>a=”[输出]”;...<//script>
[*]成为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。 比如注入
那么可以得到
文档来源：51CTO技术博客https://blog.51cto.com/u_12295205/3163831
页:
[1]