XSS概述
XSS的防禦原則
開源組件的使用
XSS（跨站腳本***）漏洞是Web應用程序中最常見的漏洞之一，它指的是惡意***者往Web頁面裏插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的html代碼會被執行，從而達到惡意***用戶的特殊目的，比如獲取用戶的cookie，導航到惡意網站，攜帶***等。根據其觸發方式的不同，可以分爲反射型XSS、存儲型XSS和DOM-base型XSS。漏洞“注入理論”認爲，所有的可輸入參數，都是不可信任的。通常我們說的不可信任的數據是指來源於HTTP客戶端請求的URL參數、form表單、Headers以及Cookies等，但是，與HTTP客戶端請求相對應的，來源於數據庫、WebServices、其他的應用接口數據也同樣是不可信的，這即是反射型XSS與存儲型XSS的本質區別。
一般來說，我們可以通過XSS漏洞的表現形式來區分漏洞是反射型、存儲型、DOM-base三種中的哪一種類型。
- 反射型XSS是指通過給別人發送帶有惡意腳本代碼參數的URL，當URL地址被打開時，帶有惡意代碼參數被HTML解析、執行。它的特點是非持久化，必須用戶點擊帶有特定參數的鏈接才能引起。它的連接形式通常如下：http://localhost/vulnerabilities/xss_r/?name=%3Cscript%3E?lert%281%29%3B%3C%2Fscript%3E其name, 參數的值爲<script>alert(1);</script>，這樣的參數值進入程序代碼後未做任何處理，從而被執行。其代碼如下圖：
2.存儲型XSS是指惡意腳本代碼被存儲進數據庫，當其他用戶正常瀏覽網頁時，站點從數據庫中讀取了非法用戶存儲的非法數據，導致惡意腳本代碼被執行。通常代碼結構如下圖：
其發生XSS的根本原因是服務器端對寫入數據庫中的內容未做javascript腳本過濾。
3.DOM-base型XSS是指在前端頁面進行DOM操作時，帶有惡意代碼的片段被HTML解析、執行，從而導致XSS漏洞。
無論是哪種類型的XSS漏洞，其解析完成後，漏洞利用的代碼基本雷同的。在日常工作中，常見的XSS漏洞Exploit***點有：
1. 惡意js的引用
2.Img標籤（以img爲例，下同）
3.大小寫繞過安全檢測
4.破壞原始標籤結構
5.基於標籤事件觸發
6.fromCharCode編碼繞過
7.javascript 轉碼
8. HTML轉碼
9. 混合型
10. CSS文本
11. CSS屬性值
基於XSS上面所述的特性，在XSS的頻發代碼中，我們通常遵循以下處理規則:
從上表中我們可以看出，ESAPI、HeadLines、AntiSamy、HTML Sanitizer 是開源組件中防禦功能比較全面的4個，其中ESAPI、HeadLines除了對XSS具有很好的防禦能力外，還對OWASP TOP 10中其他的安全漏洞都具有規範處理的能力。在單純性地討論其對XSS的防禦能力時，我們需要看具體的應用場景或者需求點。如果僅僅是對客戶端提交的簡單的請求參數（通常指form表單域，不包含複雜文本和可編輯文本）做安全過濾，則HTML Sanitizer、Java Encoder都可以作爲首選解決方案；如果不但對客戶端提交的簡單的請求參數做安全處理，而且，應用中會涉及複雜文本，類似於BBCode文本之類的數據處理，通常會首選AntiSamy作爲解決方案；如果除了以上兩點外，還需要做同源策略安全、Http Header安全、Cookies安全，則通常會首選HeadLines作爲解決方案；如果還有更多層次的用戶安全、Session會話安全、口令或隨機數安全等，則ESAPI和Apache Shiro將會被考慮。那麼，具體到某個軟件項目中，是如何使用開源組件對XSS漏洞進行防護的呢？下面就以Java語言爲例，對處理過程做簡要的闡述。
第一步：確定使用的開源組件
首選是確定使用的開源組件，只有開源組件確定下來，才能確定解決方案的細節部分。在選擇開源組件之前，要理解業務涉及的需求點，以免遺漏。一般來說，簡單文本參數使用HTML Sanitizer，複雜文本參數使用AntiSamy。
第二步：定義安全過濾器
針對於XSS的處理，常用的解決辦法是使用過濾器（Filter），由Filter中的doFilter方法對參數的內容進行安全過濾操作。其代碼核心結構如圖所示：
第三步：處理XSS
編寫處理XSS函數clearXSS時，我們會根據所選擇的開源組件不同而編寫方式有所不同。當我們把開源組件的jar和依賴庫添加到項目中之後，主要的工作是對此函數功能的實現，實現的基本思路是：從Request對象中獲取請求的參數和http消息頭，遍歷每一個參數，如果某個參數值存在XSS，則對該值進行處理（過濾、編碼、轉義、攔截等），處理完畢後再重新賦值。 如果使用HTML Sanitizer，你的核心代碼可能是
或者使用了Java Encoder，代碼類似：
如果使用了AntiSamy，代碼或許類似於：
在HTML Sanitizer和AntiSamy中，我們都看到一個詞：Policy，Policy即XSS防護策略，是指在XSS的文本進行處理時，按照怎麼的規則去處理數據塊：哪些html標籤或屬性是允許存在的，哪些的需要轉義的，哪些是需要進行格式校驗的，哪些是需要移除的等，這些都是在策略文件裏去定義的。 HTML Sanitizer組件中，包含5個預定義的策略，具體在使用中，我們可以根據自己的需求選擇某個策略。這5個策略的內容分別是：
AntiSamy組件中對策略的定義相對複雜些，是由配置文件中多個選項指定的。其配置如圖所示：
AntiSamy的策略配置是由規則（tag-rule、css-rule）來控制Antisamy對html標籤（tag）、屬性（attribute）中不可信數據做怎樣的操作行爲（action），其中操作行爲可分爲校驗（validate）、過濾（filter）、清空（truncate）、移除（remove）。根據定義的操作行爲，可以對不可信數據進行移除、清空、過濾和校驗操作。當對不可信數據進行校驗時，比如input標籤，我們可以校驗align屬性值指定枚舉值範圍爲left,right,top,middle,bottom，也可以校驗value值是否匹配既定義的正則表達式，如圖中common-regexps和common-attributes節點所示。Antisamy依據策略文件的具體配置，對傳入的不可信數據，按照定義的規則對數據進行處理，最終返回可信的文本，即代碼段中的cr.getClearHTML函數的返回值。當原來的不可信數據，經過處理變成可信數據，我們防護XSS的目的也就達到了。與HTML Sanitizer類似的是，AntiSamy除了默認的antisamy.xml外，也提供5個策略模板文件：antisamy-anythinggoes.xml、antisamy-ebay.xml、antisamy-myspace.xml、antisamy-slashdot.xml、antisamy-tinymce.xml。其中ebay的模板文件使用廣泛，在實際項目中，可以直接使用此策略模板或者在其基礎上修改即可。
第四步：添加http響應頭XSS防護
完成clearXSS函數之後名，我們需要對http響應頭添加XSS防護策略。通過clearXSS函數調用是在服務器層對XSS做防護，而添加http響應頭XSS防護策略是從客戶端瀏覽器層面防護XSS。常用的參數有：
其核心代碼大體如下：
第五步：啓用安全過濾器
完成安全過濾器對不可信數據處理的編碼邏輯之後，我們需要啓用它。啓用的過程即配置的過程，目的是使安全過濾器生效，這需要在web.xml中配置，並對所有請求進行攔截，其基本配置如下：
通過以上步驟的處理， web應用中因前端輸入導致的XSS數據基本得以解決，但在實際的項目中，發生XSS的點可能各不相同，不是僅僅用一個安全過濾器進行全局攔截處理即可託付全盤那麼簡單。例如通過文件導入引發的XSS漏洞，則需要單獨編碼，調用開源組件對XSS進行防護。總之，無論是XSS漏洞還是其他的漏洞，安全防護是一個動態的概念，在進行XSS防護過程中，我們需要根據實際情況，不斷地調整處理策略（Policy），以達到既能滿足安全需要，正確處理非法的、不安全的數據，又能滿足業務需要，不會錯誤攔截或處理了正常業務數據的最終目標。