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

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

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

兼容性

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

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

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

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

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

部署

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

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

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

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

性能

毫無(wú)疑問(wèn)，瀏覽器原生支持的肯定比模擬出來(lái)的更有效率。

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

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

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

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

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

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

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

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

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

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

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

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

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

策略配置

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

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

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

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

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

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

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

 

出現(xiàn)奇跡的時(shí)刻到來(lái)了。。。

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

日志上報(bào)

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

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

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

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

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

后記

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