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

事實(shí)上，HTML5 早已制定了一套瀏覽器XSS 解決方案 —— Content Security Policy，并且大多主流瀏覽器實(shí)現(xiàn)了這個標(biāo)準(zhǔn)。

既然我們使用前端腳本重新實(shí)現(xiàn)一遍，因此得在各個方面占有優(yōu)勢。

兼容性

CSP 目前主流瀏覽器大多已支持，IE10、11 支持部分功能。對于 IE10 之前的，當(dāng)然就束手無策了。如果使用前端腳本實(shí)現(xiàn)，可根據(jù)瀏覽器的實(shí)際能力進(jìn)退。

對于***篇介紹的 DOM-XSS，只要支持標(biāo)準(zhǔn)事件模型即可開啟，因此兼容 IE9 完全可行。

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

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

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

部署

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

而前端實(shí)現(xiàn)只需在頁面里插入個腳本就行，完全不用關(guān)心后端的部署，修改策略也無需重啟服務(wù)，維護(hù)起來容易的多。

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

當(dāng)然，如今面臨的各種問題，最終都能通過標(biāo)準(zhǔn)的完善和時代的進(jìn)步而消失。所以任何方案都只是在解決當(dāng)下的問題。

性能

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

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

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

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

頁面中使用到的腳本、插件、網(wǎng)絡(luò)通信等，都在控制臺里監(jiān)控到，并且根據(jù)策略匹配顯示不同的顏色。

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

畢竟，JavaScript 的鉤子僅僅是修改變量的字段而已，并非像傳統(tǒng)語言那樣得修改內(nèi)存權(quán)限等等。

當(dāng)然，這個頁面內(nèi)容比較少，只能看出腳本初始化的情況。

我們換個內(nèi)容非常多的頁面：

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

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

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

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

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

策略配置

使用腳本***的優(yōu)勢就在于，其策略可以靈活配置。規(guī)則可以動態(tài)產(chǎn)生，匹配也不限模式，通配符或是正則都可以。本來一切都是腳本實(shí)現(xiàn)的，何去何從完全也可由腳本決定。

當(dāng)然，為了更好的適應(yīng) CSP 標(biāo)準(zhǔn)，我們盡可能的將策略規(guī)范與標(biāo)準(zhǔn)靠近，以便相互兼容。

因?yàn)槟_本的靈活性，我們不僅支持通配符來匹配站點(diǎn)名，正則表達(dá)式也是完全支持。同時為了方便測試，調(diào)試控制臺里可以動態(tài)修改策略。

下面，我們找個存在 XSS 的頁面，立即來試驗(yàn)下： 

刷新，XSS 執(zhí)行了：

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

接著開啟我們的防火墻，為可執(zhí)行模塊配上白名單策略。只允許當(dāng)前站點(diǎn)的資源，其他的則攔截，并且發(fā)送報(bào)警日志： 

 

出現(xiàn)奇跡的時刻到來了。。。

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

日志上報(bào)

標(biāo)準(zhǔn)的 CSP 中，上報(bào)的格式是固定的，并且信息內(nèi)容也有限。但對于腳本來說，這些都不是問題，隨時可以添加想要獲得的信息。

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

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

所以，我們除了能在線預(yù)警外，還能統(tǒng)計(jì)各個地區(qū)運(yùn)行商的廣告劫持，以及一些網(wǎng)頁外掛插件。

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

后記

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