【web安全】第二弹：XSS攻防中的复合编码问题

最近一直在研究XSS的攻防，特别是dom xss，问题慢慢的迁移到浏览器编码解码顺序上去。

今儿被人放鸽子，无奈在KFC看了两个小时的资料，忽然有种豁然开朗的感受。

参考资料先贴出来：

1. http://www.freebuf.com/articles/web/43285.html

2. http://www.freebuf.com/articles/web/10121.html

3. http://www.wooyun.org/whitehats/%E5%BF%83%E4%BC%A4%E7%9A%84%E7%98%A6%E5%AD%90

4. 道哥：白帽子讲Web安全

5. 编码转换工具：http://app.baidu.com/app/enter?appid=280383

 

　　一般在XSS防护中，输出在HTML标签中或HTML属性中的状况最为常见，浏览器也只会进行HTML解码，只须要对输出进行HTML编码就能够解决XSS问题。但若是涉及输出在脚本或者URL中的时候就要进行其余方式的编码。本文的重点就是研究在复杂环境中输出变量的编码问题。

【基本知识----常见编码及原由】

 HTML编码

       在呈现HTML页面时,有时候须要显示一些特殊的字符,例如”<”和”&”,由于它们是HTML专用字符，须要经过必定的方式来实现，HTML编码由此诞生。HTML编码只是一种函数体现，用于将字符转换成HTML实体。例如想要显示<script>，在代码中须要写成“&lt;script&gt;“。为了防止XSS，至少要转换如下字符：

字符	HTML实体
<	&lt;
>	&gt;
‘	&#039;
“	&quot;
&	&amp;

　　同时字符编码也是实现HTML编码的一种形式。十进制、十六进制ASCII码或unicode字符编码，样式为“&#数值;”。例如想要显示<script>，在代码中能够写成“&#x003c;script&#x003e;”或者“&#60;script&#62;”。

Javascript编码

      JavascriptEncode能够采用跟HtmlEncode不一样的编码方式，即便用“\”对特殊字符进行转义。也能够转换成对应的字符编码。js提供了四种字符编码的策略：

　　　  一、三个八进制数字，若是不够个数，前面补0，例如“e”编码为“\145” 　　　　

　　　　二、两个十六进制数字，若是不够个数，前面补0，例如“e”编码为“\x65” 　　　　

　　　　三、四个十六进制数字，若是不够个数，前面补0，例如“e”编码为“\u0065” 　　　　

　　　　四、对于一些控制字符，使用特殊的C类型的转义风格（例如\n和\r）

URL编码

      Url参数字符串中使用key=value键值对这样的形式来传参，键值对之间以&符号分隔，如/s?q=abc&ie=utf-8。若是你的value字符串中包含了=或者&，那么势必会形成接收Url的服务器解析错误，所以必须将引发歧义的&和=符号进行转义，也就是对其进行编码。字符编码方式为：%号后面加上字符的十六进制来替换这些有冲突的字符,例如将空格替换为%20。

【浏览器解析原理】

　　浏览器在接收到一个HTML文件时，会从头开始对文档进行解析。遇到javascript时，会调用javascript解析器进行解析。遇到相似Onclick等须要触发才会执行的代码会跳过，事件被触发时才会被解析。

【实例一】

<a href="#" onclick="{$value}">天气不错</a>

浏览器解析时，onclick中的内容被当作HTML来解析。在点击连接以后，调用javascript解析器来解析$value。

因此解码的顺序：HTML解码->JavaScript解码。

因此正确的防护对策为：JavaScript编码->HTML编码。

【实例二】

<div id="bb"></div>

<script>

　　document.getElementById('bb').innerHTML="{$value}";

</script>

浏览器解析时，$value位于JavaScript中，先被Javascript解码。后$value被赋值到HTML中，进行HTML解码。

因此解码顺序为：JavaScript解码->HTML解码

因此正确的防护对策为:HTML编码->JavaScript编码

【实例三】

<td onclick=”openUrl(add.do?userName=’{$value}’);”>11</td>

浏览器解析时，$value位于Javascript中，但因为是在onclick中，因此先以HTML的身份被解码。被点击以后，先被JavaScript解码。因为$value仍是URL的一部分，因此还会被URL解码。

因此解码顺序为：HTML解码->JavaScript解码->URL解码

因此正确的防护对策为：URL编码->JavaScript编码->HTML编码

 

【写在最后】

在编码不合理的状况下的绕过方法在参考资料里写的很清楚啦，这篇文章只是整理一下思路哈~

这几天尝试着去挖挖漏洞好啦~\(^o^)/~