到目前為止，我們把能用前端腳本防御XSS 的方案都列舉了一遍。盡管看起來似乎很復雜累贅，不過那些是理論探討而已，在實際中未必要都實現。我們的目標只是為了預警，能發現問題就行，并非要做到滴水不漏的程度。

事實上，HTML5早已制定了一套瀏覽器XSS 解決方案 —— Content Security Policy，并且大多主流瀏覽器實現了這個標準。

既然我們使用前端腳本重新實現一遍，因此得在各個方面占有優勢。

兼容性

CSP 目前主流瀏覽器大多已支持，IE10、11 支持部分功能。對于 IE10 之前的，當然就束手無策了。如果使用前端腳本實現，可根據瀏覽器的實際能力進退。

對于第一篇介紹的 DOM-XSS，只要支持標準事件模型即可開啟，因此兼容 IE9 完全可行。

事實上，IE8就已開放了瀏覽器 API 接口，并支持原生訪問器的操作。所以，IE8 是支持鉤子程序，并能攔截可疑元素。

考慮到實際中，大多情況不做攔截，僅僅上報日志用以預警。對于這樣低的需求，任何版本的瀏覽器都是完全可行的，甚至連 IE6 也沒問題。

由于國內 IE 瀏覽器仍占有相當一部分比例，因此使用前端腳本的方案，能覆蓋到更廣的用戶群體中。

部署

CSP 是通過 HTTP 頭部實現的，策略配置儲存在 Content-Security-Policy 這個字段里，因此得在Web 服務器端進行配置。這對一些使用虛擬主機搭建的中小網站來說，配置起來比較麻煩。

而前端實現只需在頁面里插入個腳本就行，完全不用關心后端的部署，修改策略也無需重啟服務，維護起來容易的多。

不過，未來 CSP 會支持頁面部署，通過 meta 標簽即可配置策略，因此實用性會大幅提高。

當然，如今面臨的各種問題，最終都能通過標準的完善和時代的進步而消失。所以任何方案都只是在解決當下的問題。

性能

毫無疑問，瀏覽器原生支持的肯定比模擬出來的更有效率。

之前考慮了各種情況，需安裝各種事件和鉤子，感覺很是累贅。不過，那只是理論上防御最嚴密的情況，現實中基本只作預警，并不需監控全開。

作為測試，我們還是考慮最嚴密的情況。根據前幾篇文章探討的結果，我們做一個原型演示。

為了能線下模擬在線產品，同時做了一個 Chrome 插件，將腳本注入到在線頁面里：

頁面中使用到的腳本、插件、網絡通信等，都在控制臺里監控到，并且根據策略匹配顯示不同的顏色。

再來看性能影響。盡管我們開啟了所有的監控，但初始化消耗的時間，仍可接受。(測試環境 i3 2.3G的筆記本Win7 64位)

畢竟，JavaScript 的鉤子僅僅是修改變量的字段而已，并非像傳統語言那樣得修改內存權限等等。

　　當然，這個頁面內容比較少，只能看出腳本初始化的情況。

我們換個內容非常多的頁面：

由于嵌套了框架頁，在討論鉤子的時候我們提到，新的頁面環境也需防御，因此觸發了多次『主動防御』的初始化。

『靜態掃描』的內容，正是被 MutationObserver 捕獲的元素。由于頁面內容非常多，靜態元素也是隨著 HTML 文檔邊下載邊展現的。盡管掃描累計時間并不少，但相對整個頁面加載的數秒時間，也基本忽略不計了。

『動態掃描』的內容，則是后期通過腳本創建的。隨著滾動條往下拉，掃描次數也逐漸增多。由于我們勾住了 createElement ，理論上說調用會慢一些。不過現實中很少會一口氣大量調用該方法的，大多使用模板通過 innerHTML 批量創建。

另外，我們還勾住了 setAttribute 這個常用的方法，統計結果和『訪問器鉤子』一起納入在『屬性檢驗』里。不過，現實中大多場合并不需要調用這個方法，畢竟從 attribute 到 property 還得經過一次字符串的解析，能直接用 property 則完全沒必要去 setAttribute。

而訪問器鉤子，只有在修改 script、embed 這些元素的 src 屬性時才會觸發，這些操作本來就很少，因此屬性掃描的額外消耗還是可以忽略的。

策略配置

使用腳本最大的優勢就在于，其策略可以靈活配置。規則可以動態產生，匹配也不限模式，通配符或是正則都可以。本來一切都是腳本實現的，何去何從完全也可由腳本決定。

當然，為了更好的適應 CSP 標準，我們盡可能的將策略規范與標準靠近，以便相互兼容。

因為腳本的靈活性，我們不僅支持通配符來匹配站點名，正則表達式也是完全支持。同時為了方便測試，調試控制臺里可以動態修改策略。

下面，我們找個存在 XSS 的頁面，立即來試驗下：

　　雖然是非同源執行的，但好歹也算個 XSS。我們就拿它來測試。

接著開啟我們的防火墻，為可執行模塊配上白名單策略。只允許當前站點的資源，其他的則攔截，并且發送報警日志：

　　出現奇跡的時刻到來了。。。

　　站外的可疑模塊成功攔截了!同時開始發送預警日志到后臺。

日志上報

標準的 CSP 中，上報的格式是固定的，并且信息內容也有限。但對于腳本來說，這些都不是問題，隨時可以添加想要獲得的信息。

你肯定會覺得，上報的數量不會太多，存在漏洞的畢竟只是少數。不過，廣義上的 XSS 未必都是由漏洞引起的。

XSS —— CrossSiteScript，只要是頁面里的站外的腳本，都可以算是。通常情況下只能由漏洞引起，但在一些特殊的場合，任意頁面都可能出現站外腳本，例如之前討論的流量劫持，或是瀏覽器插件，都是很常見的情況。

所以，我們除了能在線預警外，還能統計各個地區運行商的廣告劫持，以及一些網頁外掛插件。

當然，想繞過也是很容易的。只要在流量上過濾了我們的防御腳本，或是屏蔽日志發送，我們都是無從得知的。

后記

事實上，最終的方案已上線。盡管只抽樣了極少量的用戶，但仍傳回上百萬的預警日志。幾乎所有都是廣告劫持和瀏覽器插件，即使存在漏洞暫時也無法得知，我們不可能一個個去分析復現。因此，我們還需一套高效的復現系統，來幫助我們實現自動化的復現工作。