原理:利用网页开发时web应用程序对用户输入过滤不足导致将恶意代码注入到网页中,使用户浏览器加载并执行恶意代码,通常是JavaScript类型,也包括java、vbs、flash、html等。
解码的顺序是HTML,URL和JavaScript。
常用的测试方法:alert、confirm、prompt
第一题:
<a href="%6a%61%76%61%73%63%72%69%70%74:%61%6c%65%72%74%28%31%29">aaa</a>
执行不了。%6a%61%76%61%73%63%72%69%70%74和 %61%6c%65%72%74%28%31%29为url的编码
解码为:<a href="script:alert(1)">aaa</a> ,但是href不认识url的编码,所以不能执行
第二题:
<a href="javascript:%61%6c%65%72%74%28%32%29">
执行得了,因为先经过html的解码。而 以&#的是以html的实体编码,所以可以运行
第三题:
<a href="javascript%3aalert(3)">ccc</a>
执行不了 ,一样的道理,%3a为url编码,href识别不了
第四题:
<div><img src=x onerror=alert(4)></div>
执行不了。解析器在解析这个字符引用后不会转换到“标签开始状态”。正因为如此,就不会建立新标签。因此,我们能够利用字符实体编码这个行为来转义用户输入的数据从而确保用户输入的数据只能被解析成“数据”。从HTML解析机制看,在读取<div>
之后进入数据状态,<
会被HTML解码,但不会进入标签开始状态,当然也就不会创建img
元素,也就不会执行
第五题:
<textarea><script>alert(5)</script></textarea>
执行不了。 以上编码可以被解码,但是会以原样输出,原因如下
可以看出<textarea>标签为RCDATA元素,只可以容纳文本和字符引用
第六题:
<button onclick="confirm('7');">Button</button>
可以执行,因为'被html解码成了'
第七题:
<button onclick="confirm('8\u0027);">Button</button>
执行不了。在JS中只有字符串和标识符能用Unicode表示,'
显然不行,JS执行失败
第八题:
<script>alert(9);</script>
执行不了。在上面例子中提过,script属于原始文本元素,可以容纳文本,但是没有字符引用,所以不能对我们的编码进行解码,所以不能执行
第九题:
<script>\u0061\u006c\u0065\u0072\u0074(10);</script>
可以执行。直接当成文本提交,然后会对url编码进行解码,所以可以执行
第十题:
<script>\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029</script>
执行不了。一样的道理在JS中只有字符串和标识符能用Unicode表示,所以不能执行
第十一题:
<script>\u0061\u006c\u0065\u0072\u0074(\u0031\u0032)</script>
不能执行。这里看似将没毛病,但是这里\u0031\u0032
在解码的时候会被解码为字符串12
,注意是字符串,不是数字,文字显然是需要引号的,JS执行失败
第十二题:
<script>alert('13\u0027)</script>
执行不了。 一样的道理在JS中只有字符串和标识符能用Unicode表示,所以不能执行
第十三题:
<script>alert('14\u000a')</script>
可以执行。\u000a
在JavaScript里是换行,就是\n,
相当于在源码里直接按一下回车键,可以执行
第十四题:
<a href="javascript:%5c%75%30%30%36%31%5c%75%30%30%36%63%5c%75%30%30%36%35%5c%75%30%30%37%32%5c%75%30%30%37%34(15)"></a>
在href中由URL模块处理,解码得到
javascript:\u0061\u006c\u0065\u0072\u0074(15)
识别JS协议,然后由JS模块处理,解码得到
javascript:alert(15)
最后被执行