目前UTF-8 字符集比較可靠

但是如果服務(wù)器在響應(yīng)的時候，沒有對Content-type:text/heml;charset=utf-8 做強制制定，會導(dǎo)致安全風(fēng)險，因為很有可能在某些字符集下會執(zhí)行特定script語句。

例如：
<?php header("Content-Type: text/html;charset=GBK");?>
<script>
a="<?php echo $_GET['x'];?>"
</script>
如果magic_quote_gpc=On，此時繞過方法是使用GBK編碼的高低字節(jié)組合方式來繞過對雙引號的" 轉(zhuǎn)義。（GBK高字節(jié)范圍0x81-0xFE 低字節(jié)范圍 0x40-0x7e 和 0x80-0xFE）
提交方法 1%81”;alert(1)// 此時[0x81]是高字節(jié)方位，則與轉(zhuǎn)義后的\（0x5c） 低字節(jié)位組合，于是在GBK編碼方式下，將\去掉。

有一些跨站是不需要輸入尖括號的

<IMG SRC=j&#X41vascript:alert('test2')>
<a href="javascript:eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))">
所以這種情況下，需要注意對一些特殊符號的解析。解析方式是對編碼的順序進(jìn)行確認(rèn)，例如HTML的encode，javascript 的encode， URL的encode，以及CSS的encode。

注意瀏覽器渲染順序，在程序encode 過濾的時候與瀏覽器渲染順序相反

如：
<a ID="test" onclick="alert('test')" >test's link</a>
瀏覽器解析順序是
<a ----- HTML
onclick ----- Javascript
那么過濾順序則是 先將用戶輸入的參數(shù) 以 javascript encode 過濾，再將參數(shù)以 html 參數(shù)過濾。所以，對用戶提交的參數(shù)不僅僅需要編碼，而且也要注意編碼順序

參考

關(guān)于UTF gb2312 編碼之類的總結(jié)
http://www.cnblogs.com/skynet/archive/2011/05/03/2035105.html
老外關(guān)于utf字符集研究和吐槽
http://www.joelonsoftware.com/articles/Unicode.html
該問題展示了如果需要給其他國家用戶訪問，在避免跨站上面的方法
http://stackoverflow.com/questions/804969/utf-8-characters-that-arent-xss-vulnerabilities
該文檔暫時了利用其他非utf編碼來進(jìn)行跨站的方法
http://zaynar.co.uk/docs/charset-encoding-xss.html
解釋了為什么統(tǒng)一utf8編碼技術(shù)會減少跨站風(fēng)險
http://security.stackexchange.com/questions/35741/xss-via-unicode
XSS防范技術(shù)匯總
http://www.xssed.com/xssinfo#Avoiding_XSS_vulnerabilities
Unicode 繞過xss
https://barracudalabs.com/2009/06/unicode-encoding-for-bypassing-xss-filters/
《web前端黑客技術(shù)》