關于 XSS 怎樣形成、如何注入、能做什么、如何防范，前人已有無數的探討，這里就不再累述了。本文介紹的則是另一種預防思路。
? ?? ??幾乎每篇談論 XSS 的文章，結尾多少都會提到如何防止，然而大多萬變不離其宗。要轉義什么，要過濾什么，不要忘了什么之類的。盡管都是眾所周知的道理，但 XSS 漏洞十幾年來幾乎從未中斷過，不乏一些大網站也時常爆出，小網站更是家常便飯。
預警系統
? ?? ??事實上，至今仍未有一勞永逸的解決方案，要避免它依舊使用最古老的土辦法，逐個的過濾。然而人總有疏忽的時候，每當產品迭代更新時，難免會遺漏一些新字段，導致漏洞被引入。
? ?? ??即使圣人千慮也有一失，程序出 BUG 完全可以理解，及時修復就行。但令人費解的是，問題出現到被發現，卻要經過相當長的時間。例如不久前貼吧 XSS 蠕蟲腳本，直到大規模爆發后經用戶舉報，最終才得知。其他網站大多也類似，直到白帽子們挖掘出漏洞，提交到安全平臺上，最終廠商才被告知。若遇到黑客私下留著這些漏洞慢慢利用，那只能聽天由命了。
? ?? ??因此，要是能有一套實時的預警系統，那就更好了。即使無法阻止漏洞的發生，但能在漏洞觸發的第一時間里，通知開發人員，即可在最短的時間里修復，將損失降到最低。各式各樣的應用層防火墻，也由此產生。
? ?? ??不過，和傳統的系統漏洞不同，XSS 最終是在用戶頁面中觸發的。因此，我們不妨嘗試使用前端的思路，進行在線防御。
DOM 儲存型 XSS
? ?? ??先來假設一個有 BUG 的后臺，沒有很好處理用戶輸入的數據，導致 XSS 能被注入到頁面：
<img src="{路徑}" />
<img src="{路徑" onload="alert(/xss/)}" />
?
? ?? ??只轉義尖括號，卻忘了引號，是 XSS 里最為常見的。攻擊者們可以提前關閉屬性，并添加一個極易觸發的內聯事件，跨站腳本就這樣被輕易執行了。
? ?? ??那么，我們能否使用前端腳本來捕獲，甚至攔截呢？
被動掃描
? ?? ??最簡單的辦法，就是把頁面里所有元素都掃描一遍，檢測那些 on 開頭的內聯屬性，看看是不是存在異常：
? ?? ??例如字符數非常多，正常情況下這是很少出現的，但 XSS 為了躲避轉義有時會編碼的很長；例如出現一些 XSS 經常使用的關鍵字，但在實際產品里幾乎不會用到的。這些都可以作為漏洞出現的征兆，通知給開發人員。
? ?? ??不過，土辦法終究存在很大的局限性。在如今清一色的 AJAX 時代，頁面元素從來都不是固定的。伴隨著用戶各種交互，新內容隨時都可能動態添加進來。即使換成定期掃描一次，XSS 也可能在定時器的間隔中觸發，并銷毀自己，那樣永遠都無法跟蹤到了。況且，頻繁的掃描對性能影響也是巨大的。
? ?? ??如同早期的安全軟件一樣，每隔幾秒掃描一次注冊表啟動項，不僅費性能，而且對惡意軟件幾乎不起作用；但之后的主動防御系統就不同了，只有在真正調用 API 時才進行分析，不通過則直接攔截，完全避免了定時器的間隔遺漏。
? ?? ??因此，我們需要這種類似的延時策略 —— 僅在 XSS 即將觸發時對其分析，對不符合策略的元素，進行攔截或者放行，同時發送報警到后臺日志。
主動防御
? ?? ??『主動防御』，這概念放在前端腳本里似乎有些玄乎。但不難發現，這僅僅是執行優先級的事而已 —— 只要防御程序能運行在其他程序之前，我們就有了可進可退的主動權。對于無比強大的 HTML5 和靈活多變的 JavaScript，這些概念都可以被玩轉出來。
? ?? ??繼續回到剛才討論的內聯事件 XSS 上來。瀏覽器雖然沒提供可操控內聯事件的接口，但內聯事件的本質仍是一個事件，無論怎樣變化都離不開 DOM 事件模型。
? ?? ??扯到模型上面，一切即將迎刃而解。模型是解決問題的最靠譜的辦法，尤其是像?DOM-3-Event(
http://www.w3.org/TR/DOM-Level-3-Events/
)這種早已制定的模型，其穩定性毋庸置疑。
? ?? ??即便沒仔細閱讀官方文檔，但凡做過網頁的都知道，有個 addEventListener 的接口，并取代了曾經一個古老的叫 attachEvent 的東西。盡管只是新增了一個參數而已，但正是這個差別成了人們津津樂道的話題。每當面試談到事件時，總少不了考察下這個新參數的用途。盡管在日常開發中很少用到它。
? ?? ??關于事件捕獲和冒泡的細節，就不多討論了。下面的這段代碼，或許能激發你對『主動防御』的遐想。
<button onclick="console.log('target')">CLICK ME</button>
<script>
document.addEventListener('click', function(e) {
console.log('bubble');
});
document.addEventListener('click', function(e) {
console.log('capture');
//e.stopImmediatePropagation();
}, true);
</script>
?
Run(
http://jsfiddle.net/zjcqoo/v9wm5/
)
? ?? ??盡管按鈕上直接綁了一個內聯的事件，但事件模型并不買賬，仍然得按標準的流程走一遍。capture，target，bubble，模型就是那樣固執。
? ?? ??不過，把那行注釋的代碼恢復，結果就只剩 capture 了。這個簡單的道理大家都明白，也沒什么好解釋的。
? ?? ??但仔細揣摩下，這不就是『主動防御』的概念嗎？捕獲程序運行在內聯事件觸發之前，并且完全有能力攔截之后的調用。
? ?? ??上面的 Demo 只是不假思索攔截了所有的事件。如果我們再加一些策略判斷，或許就更明朗了：
<button onclick="console.log('xss')">CLICK ME</button>
<script>
document.addEventListener('click', function(e) {
console.log('bubble');
});
document.addEventListener('click', function(e) {
var element = e.target;
var code = element.getAttribute('onclick');
if (/xss/.test(code)) {
e.stopImmediatePropagation();
console.log('攔截可疑事件:', code);
}
}, true);
</script>
?
?
Run(
http://jsfiddle.net/zjcqoo/r93Sv/
)
? ?? ??我們先在捕獲階段掃描內聯事件字符，若是出現了『xss』這個關鍵字，后續的事件就被攔截了；換成其他字符，仍然繼續執行。同理，我們還可以判斷字符長度是否過多，以及更詳細的黑白名單正則。
? ?? ??怎么樣，一個主動防御的原型誕生了吧。
? ?? ??不過，上面的片段還有個小問題，就是把事件的冒泡過程也給屏蔽了，而我們僅僅想攔截內聯事件而已。解決辦法也很簡單，把 e.stopImmediatePropagation() 換成 element.onclick = null 就可以了。
? ?? ??當然，目前這只能防護 onclick，而現實中有太多的內聯事件。鼠標、鍵盤、觸屏、網絡狀態等等，不同瀏覽器支持的事件也不一樣，甚至還有私有事件，難道都要事先逐一列出并且都捕獲嗎？是的，可以都捕獲，但不必事先都列出來。
? ?? ??因為我們監聽的是 document 對象，瀏覽器所有內聯事件都對應著 document.onxxx 的屬性，因此只需運行時遍歷一下 document 對象，即可獲得所有的事件名。
<img src="*" onerror="console.log('xss')" />
<script>
function hookEvent(onevent) {
document.addEventListener(onevent.substr(2), function(e) {
var element = e.target;
if (element.nodeType != Node.ELEMENT_NODE) {
return;
}
var code = element.getAttribute(onevent);
if (code && /xss/.test(code)) {
element[onevent] = null;
console.log('攔截可疑事件:', code);
}
}, true);
}
console.time('耗時');
for (var k in document) {
if (/^on/.test(k)) {
//console.log('監控:', k);
hookEvent(k);
}
}
console.timeEnd('耗時');
</script>
?
Run(
http://jsfiddle.net/zjcqoo/yNH7V/
)
? ?? ??現在，無論頁面中哪個元素觸發哪個內聯事件，都能預先被我們捕獲，并根據策略可進可退了。
性能優化
? ?? ??或許有些事件沒有必要捕獲，例如視頻播放、音量調節等，但就算全都捕捉也耗不了多少時間，基本都在 1ms 左右。
? ?? ??當然，注冊事件本來就花不了多少時間，真正的耗費都算在回調上了。盡管大多數事件觸發都不頻繁，額外的掃描可以忽律不計。但和鼠標移動相關的事件那就不容忽視了，因此得考慮性能優化。
? ?? ??顯然，內聯事件代碼在運行過程中幾乎不可能發生變化。使用內聯事件大多為了簡單，如果還要在運行時 setAttribute 去改變內聯代碼，完全就是不可理喻的。因此，我們只需對某個元素的特定事件，掃描一次就可以了。之后根據標志，即可直接跳過。
<div style="width:100%; height:100%; position:absolute" onmouseover="console.log('xss')"></div>
<script>
function hookEvent(onevent) {
document.addEventListener(onevent.substr(2), function(e) {
var element = e.target;
// 跳過已掃描的事件
var flags = element['_flag'];
if (!flags) {
flags = element['_flag'] = {};
}
if (typeof flags[onevent] != 'undefined') {
return;
}
flags[onevent] = true;
if (element.nodeType != Node.ELEMENT_NODE) {
return;
}
var code = element.getAttribute(onevent);
if (code && /xss/.test(code)) {
element[onevent] = null;
console.log('攔截可疑代碼:', code);
}
}, true);
}
for (var k in document) {
if (/^on/.test(k)) {
hookEvent(k);
}
}
</script>
?
Run(
http://jsfiddle.net/zjcqoo/9chsb/
)
? ?? ??這樣，之后的掃描僅僅是判斷一下目標對象中的標記而已。即使瘋狂晃動鼠標，CPU 使用率也都忽略不計了。
? ?? ??到此，在 XSS 內聯事件這塊，我們已實現主動防御。
? ?? ??對于有著大量字符，或者出現類似 String.fromCharCode，$.getScript 這類典型 XSS 代碼的，完全可以將其攔截；發現有 alert(/xss/)，alert(123) 這些測試代碼，可以暫時放行，并將日志發送到后臺，確定是否能夠復現。
? ?? ??如果復現，說明已有人發現 XSS 并成功注入了，但還沒大規模開始利用。程序猿們趕緊第一時間修 BUG 吧，讓黑客忙活一陣子后發現漏洞已經修復了：）
字符策略的缺陷
? ?? ??但是，光靠代碼字符串來判斷，還是會有疏漏的。尤其是黑客們知道有這么個玩意存在，會更加小心了。把代碼轉義用以躲避關鍵字，并將字符存儲在其他地方，以躲過長度檢測，即可完全繞過我們的監控了：
<img src="*" onerror="window['ev'+'al'](this.align)" align="alert('a mass of code...')">
?
? ?? ??因此，我們不僅需要分析關鍵字。在回調執行時，還需監控 eval、setTimeout('...') 等這類能解析代碼的函數被調用。
? ?? ??不過，通常不會注入太多的代碼，而是直接引入一個外部腳本，既簡單又靠譜，并且能實時修改攻擊內容：
<img src="*" onerror="$['get'+'Script'](...)">
?
? ?? ?以上就是本次的討論，稍后討論如何攔截可疑的外部模塊。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
