Web2.0時代，XSS漏洞不容小覷。特別是在UGC業務，支持“安全的”HTML是業務必須的特性，這就對UGC安全過濾器要求特別高，稍有不慎就會出現存儲XSS漏洞。
整篇文章著眼點在“方案”，后續有機會我們還可以說說API的運營故事(這個元老級項目故事很多)。通過對API的精細化運營是可以發現0day漏洞的——API自身的，甚至包括瀏覽器。比如CVE-2009-1862、CVE-2011-2458 以及一些其他八卦。
存儲型XSS漏洞，這個作為漏洞界的元老級漏洞類型，在當前web2.0時代，一旦被利用，對業務造成的影響也將是轟轟烈烈的，比如之前的“XX咖啡廣告”：
本文的主要目的是和大家一起探討在支持業務富文本UGC的前提下，如何有效解決存儲XSS漏洞，如果有寫的不對或遺漏的地方，歡迎大家及時指正。
提到XSS漏洞，很多人可能第一印象就是把已公開的xsscode弄個正則全部屏蔽就萬事大吉，但是往往事與愿違，付出了巨大的努力，XSS漏洞還依然存在。本文就根據XSS漏洞生成原理來逐個講講如何有效解決該問題。
一：整體過濾流程圖
廢話少說，直接看過濾流程圖：
二：屬性值過濾
針對過濾流程中的標簽及黑屬性，這里就不多說了，發現刪除就可以，具體是哪些標簽及屬性可參考附件的配置文件，這里重點說下屬性值安全
談到屬性值，才算正式進入本篇的重點，屬性值大體分為3類
2.1 URL
這里指的URL，就是類似href，src等的值，這里核心的就是按照URL標準識別出引入的URL的協議，保留允許的協議即可，比如
2.2 CSS
為什么要提到CSS呢，因為CSS是富文本UGC的一個核心，因為沒有CSS，QQ空間日志內容則達不到用戶想要的炫酷效果，為了保證CSS的安全，我們又得再實現一個CSS語法解析器(由于當時場景需要，我們是自己寫的，不過大家也可以參考CSS Parse的開源代碼)。
由于CSS的強大，所以我們首先定義了一串黑名單，比如出現expression，background，javascript，eval一旦出現這些黑名單，這里之前犯過一個錯誤，就是采用刪除邏輯，當遇到下面的case，真的是欲哭無淚，后來評估正常UGC，極少出現黑名單里的用法，so直接清空css。
坑1：在完成黑名單清理后，你會發現IE瀏覽器竟然兼容如下格式的CSS(強大的)
坑2：同時IE還兼容如下格式(&#編碼，尼瑪的支持編碼就算了，最后的;還可有可無)
坑3：你以為他只認識html編碼嘛，其實你錯了，他還認識unicode編碼。
沒辦法，統統黑名單搞之：出現 或 &# 統統清空CSS啊，清空CSS。
坑4：此時，你以為CSS應該沒事了，但是IE又出現新的兼容方式：全角字符
繼續搞，只要出現全角字符，一概清空。
2.3 Flash
講到Flash安全，就重點保障2個屬性值設置合理就行了：
allowScriptAccess： & allowNetworking
如果條件允許建議統一設置為：allowScriptAccess設置為never，allowNetworking設置為none
但是業務往往需要這2個屬性，比如QQ空間日志中要能播放QQ音樂，所以需要首先識別出引入的Flash地址，然后僅對白名單的放開該權限即可。
這里強烈建議大家不要使用object，因為他比embed處理要麻煩N倍，同時IE大爺對它兼容也超好，比如當識別屬性名時，如下編碼格式也是允許的：
三：重寫
打完收工的最后一步，也是蠻重要的一步，重寫這里之前遇到個坑，就是嚴格安全用戶的閉合字符來做，導致被繞的死去活來，后來一了百了，按照HTML標準直接強制雙引號閉合，屬性值全部編碼過濾。
注：DOM解析識別出style的閉合字符為空格，在丟棄無效的css后，結果變成了有漏洞的版本了。
四：方案的弊端
該方案要過濾的標簽、屬性都是要提前已知的，如果出現新標簽，則要及時更新，不然會出現XSS漏洞，這里就經歷過2次，第一次為html5新增標簽、第二次則為LISTING特性。
附：過濾XSS利用代碼的可執行程序及配置文件
使用方法如下：(demo運行環境為gcc4 & linux32位系統)
./demo_filterall_aa輸入文件 1 1 輸出文件
輸入為用戶的UGC：test.html
過濾后結果為：
京公網安備 11010502049343號