xss作为江湖上一种常见的攻击手段，一直有广泛的使用。然而怎么样发现一个交互的地方是否会有xss漏洞呢？有一些通用的手动挖掘思路分享
常用攻击代码：
首先，找到一个你觉得可能会有问题的地方。然后提交这一段代码，如果出现了弹窗，或者打开开发者，发现报了错。那么恭喜你~找到一个xss漏洞啦。
playload分析:
上面的那段代码，刚拿来看的时候，可能会恨疑惑这是些什么东西。这是因为，这一长串代码讲所有可能的场景都包含在内了。首先，我们并不知道我们提交之后，服务器返回的response会出现在什么地方。一般来说，会出现在一下几个地方：
html标签之间 -》</防过滤/div >[输出]< /防过滤/ /div>
html标签之内 -》</防过滤/input type=”text” value=”[输出]” />
成为javascript代码-》</防过滤/script>a=”[输出]”;...<//script>
成为css代码-》</防过滤/style>body{font-size:[输出]px;...}<//style>
如果输出结果在标签之间
场景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=http://www.likecs.com/”[输出]”>click me</ //a>: 我们的payload可以像下面这个样子
前提是我们提交的payload必须出现在这些属性值的开头部分(data协议必须作为整个属性值出现)。对于第一个伪协议，所有的浏览器都支持，不过有一些差异。对于第二个data协议，对于IE不支持。另外，我们提交的这两个payload是可以进行一些混淆的，这样可以更好的绕过过滤机制。
看javascrip/防过滤/:alert(1)这个payload的场景，如果输出一下语句
如果输出在on事件中。根据不同的场景，我们需要弄清楚我们的输出是整个on事件值出现，还是以某个函数的参数值出现，这个函数是什么等。不同的出现场景可能需要不同的闭合策略。最终目标都是让我们的脚本都能顺利执行。 最神奇的是
和场景5类似，有些js代码是服务端输出的，有时会将用户提交的值作为js代码的一部分输出，如以下场景
在这个场景中，我们的payload可以是
他会优先寻找最近的一个script标签闭合，无论这个script标签出现在哪里，都会导致payload成功。 成为css代码