XSS转码
XSS转码引发的过滤问题
有攻就有防，网站程序员肯定不会放任大家利用XSS，所以他们常会过滤类似javascript的关键字符，让大家构造不了自己的XSS，我这里就捡两个被忽略惯了的字符来说，它们是"&"和"\".首先来说说"&"字符，玩过SQL注入的都知道，注入的语句可以转成16进制再赋给一个变量运行，XSS的转码和这个还真有异曲同工之妙，原因是我们的IE浏览器默认采用的是UNICODE编码，HTML编码可以用&#ASCII方式来写，这种XSS转码支持10进制和16进制，SQL注入转码是将16进制字符串赋给一个变量，而XSS转码则是针对属性所赋的值，下面我就拿<img src="javascript:alert('XSS');">示例：
<img src="javascript:alert('XSS');"> //10进制转码 如图：
|
|
<img src="javascript:alert('XSS');"> //16进制转码。
这个&#分隔符还可以继续加0变成“j” ，“j” ，“j” ，“j”等形式。
而这个"\"字符却暴露了一个严重的XSS 0DAY漏洞，这个漏洞和CSS（Cascading Style Sheets）层叠样式表有很大的关联，下面我就来看看这个漏洞，先举个javascript的eval 函数的例子，官方是这样定义这个函数：
eval(codeString)，必选项 codestring 参数是包含有效 JScript 代码的字符串值。这个字符串将由 JScript 分析器进行分析和执行。
我们的JavaScript中的"\"字符是转义字符，所以可以使用"\"连接16进制字符串运行代码
<SCRIPT LANGUAGE="JavaScript">
eval("\x6a\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3a\x61\x6c\x65\x72\x74\x28\x22\x58\x53\x53\x22\x29")
</SCRIPT>
恐怖的是样式表也支持分析和解释"\"连接的16进制字符串形式，浏览器能正常解释。下面我们来做个实验：
写一个指定某图片为网页背景的CSS标记：
<html>
<body>
<style>
BODY { background: url(http://127.0.0.1/xss.gif) }
</style>
<body>
<html>
保存为HTM，浏览器打开显示正常。
转换background属性值为"\"连接的16进制字符串形式，浏览器打开同样显示正常。
<html>
<body>
<style>
BODY { background:
\75\72\6c\28\68\74\74\70\3a\2f\2f\31\32\37\2e\30\2e\30\2e\31\2f\78\73\73\2e\67\69\66\29
}
</style>
<body>
<html>
在文章第一部分我已经说过XSS的触发条件包括访问文件的标记属性，因此我们不难构造出
<img STYLE="background-image: url(javascript:alert('XSS'))">
这样的XSS语句。有了实验的结果，我们又能对CSS样式表的标记进行XSS转码，浏览器将帮我们解释标记内容，XSS语句示例：
<img STYLE="background-image: \75\72\6c\28\6a\61\76\61\73\63\72\69\70\74\3a\61\6c\65\72\74\28\27\58\53\53\27\29\29"> 看图：
|
|
编者语：XSS攻击以及的可怕性及灵活性深受黑客的喜爱。争对XSS攻击，编者给普通浏览网页用户及WEB应用开发者给出以下的安全建议：
web用户
1.在电子邮件或者即时通讯软件中点击链接时需要格外小心：留心可疑的过长链接，尤其是它们看上去包含了HTML代码。如果对其产生怀疑，可以在浏览器地址栏中手工输入域名，而后通过该页面中的链接浏览你所要的信息。
2.对于XSS漏洞，没有哪种web浏览器具有明显的安全优势。就是Firefox也同样不安全。为了获得更多的安全性，可以安装一些浏览器插件：比如Firefox的NoScript或者Netcraft工具条。
3.世界上没有“100%的有效”。尽量避免访问有问题的站点：比如提供hack信息和工具、破解软件、成人照片的网站。这些类型的网站会利用浏览器漏洞并危害操作系统。
web应用开发者
1.对于开发者，首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括URL、查询关键字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。
2.保护所有敏感的功能，以防被bots自动化或者被第三方网站所执行。实现session标记（session tokens）、CAPTCHA系统或者HTTP引用头检查。
3.如果你的web应用必须支持用户提供的HTML，那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点：确认你接收的HTML内容被妥善地格式化，仅包含最小化的、安全的tag（绝对没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和JavaScript）。为了更多的安全，请使用httpOnly的cookie。
