關於 XSS 怎樣形成、如何注入、能做什麼、如何防範,前人已有無數的探討,這裡就不再累述了。本文介紹的則是另一種預防思路。
幾乎每篇談論 XSS 的文章,結尾多少都會提到如何防止,然而大多萬變不離其宗。要轉義什麼,要過濾什麼,不要忘了什麼之類的。儘管都是眾所周知的道理,但 XSS 漏洞十幾年來幾乎從未中斷過,不乏一些大網站也時常爆出,小網站更是家常便飯。
預警系統
事實上,至今仍未有一勞永逸的解決方案,要避免它依舊使用最古老的土辦法,逐個的過濾。然而人總有疏忽的時候,每當產品迭代更新時,難免會遺漏一些新欄位,導致漏洞被引入。
即使聖人千慮也有一失,程式出 BUG 完全可以理解,及時修復就行。但令人費解的是,問題出現到被發現,卻要經過相當長的時間。例如不久前貼吧 XSS 蠕蟲指令碼,直到大規模爆發後經使用者舉報,最終才得知。其他網站大多也類似,直到白帽子們挖掘出漏洞,提交到安全平臺上,最終廠商才被告知。若遇到黑客私下留著這些漏洞慢慢利用,那隻能聽天由命了。
因此,要是能有一套實時的預警系統,那就更好了。即使無法阻止漏洞的發生,但能在漏洞觸發的第一時間裡,通知開發人員,即可在最短的時間裡修復,將損失降到最低。各式各樣的應用層防火牆,也由此產生。
不過,和傳統的系統漏洞不同,XSS 最終是在使用者頁面中觸發的。因此,我們不妨嘗試使用前端的思路,進行線上防禦。
DOM 儲存型 XSS
先來假設一個有 BUG 的後臺,沒有很好處理使用者輸入的資料,導致 XSS 能被注入到頁面:
1 2 3 |
<img src="{路徑}" /> <img src="{路徑" onload="alert(/xss/)}" /> |
只轉義尖括號,卻忘了引號,是 XSS 裡最為常見的。攻擊者們可以提前關閉屬性,並新增一個極易觸發的內聯事件,跨站指令碼就這樣被輕易執行了。
那麼,我們能否使用前端指令碼來捕獲,甚至攔截呢?
被動掃描
最簡單的辦法,就是把頁面裡所有元素都掃描一遍,檢測那些 on 開頭的內聯屬性,看看是不是存在異常:
例如字元數非常多,正常情況下這是很少出現的,但 XSS 為了躲避轉義有時會編碼的很長;例如出現一些 XSS 經常使用的關鍵字,但在實際產品裡幾乎不會用到的。這些都可以作為漏洞出現的徵兆,通知給開發人員。
不過,土辦法終究存在很大的侷限性。在如今清一色的 AJAX 時代,頁面元素從來都不是固定的。伴隨著使用者各種互動,新內容隨時都可能動態新增進來。即使換成定期掃描一次,XSS 也可能在定時器的間隔中觸發,並銷燬自己,那樣永遠都無法跟蹤到了。況且,頻繁的掃描對效能影響也是巨大的。
如同早期的安全軟體一樣,每隔幾秒掃描一次登錄檔啟動項,不僅費效能,而且對惡意軟體幾乎不起作用;但之後的主動防禦系統就不同了,只有在真正呼叫 API 時才進行分析,不通過則直接攔截,完全避免了定時器的間隔遺漏。
因此,我們需要這種類似的延時策略 —— 僅在 XSS 即將觸發時對其分析,對不符合策略的元素,進行攔截或者放行,同時傳送報警到後臺日誌。
主動防禦
『主動防禦』,這概念放在前端指令碼里似乎有些玄乎。但不難發現,這僅僅是執行優先順序的事而已 —— 只要防禦程式能執行在其他程式之前,我們就有了可進可退的主動權。對於無比強大的 HTML5 和靈活多變的 JavaScript,這些概念都可以被玩轉出來。
繼續回到剛才討論的內聯事件 XSS 上來。瀏覽器雖然沒提供可操控內聯事件的介面,但內聯事件的本質仍是一個事件,無論怎樣變化都離不開 DOM 事件模型。
扯到模型上面,一切即將迎刃而解。模型是解決問題的最靠譜的辦法,尤其是像 DOM-3-Event 這種早已制定的模型,其穩定性毋庸置疑。
即便沒仔細閱讀官方文件,但凡做過網頁的都知道,有個 addEventListener 的介面,並取代了曾經一個古老的叫 attachEvent 的東西。儘管只是新增了一個引數而已,但正是這個差別成了人們津津樂道的話題。每當面試談到事件時,總少不了考察下這個新引數的用途。儘管在日常開發中很少用到它。
關於事件捕獲和冒泡的細節,就不多討論了。下面的這段程式碼,或許能激發你對『主動防禦』的遐想。
1 2 3 4 5 6 7 8 9 10 11 |
<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> |
儘管按鈕上直接綁了一個內聯的事件,但事件模型並不買賬,仍然得按標準的流程走一遍。capture,target,bubble,模型就是那樣固執。
不過,把那行註釋的程式碼恢復,結果就只剩 capture 了。這個簡單的道理大家都明白,也沒什麼好解釋的。
但仔細揣摩下,這不就是『主動防禦』的概念嗎?捕獲程式執行在內聯事件觸發之前,並且完全有能力攔截之後的呼叫。
上面的 Demo 只是不假思索攔截了所有的事件。如果我們再加一些策略判斷,或許就更明朗了:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<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> |
我們先在捕獲階段掃描內聯事件字元,若是出現了『xss』這個關鍵字,後續的事件就被攔截了;換成其他字元,仍然繼續執行。同理,我們還可以判斷字元長度是否過多,以及更詳細的黑白名單正則。
怎麼樣,一個主動防禦的原型誕生了吧。
不過,上面的片段還有個小問題,就是把事件的冒泡過程也給遮蔽了,而我們僅僅想攔截內聯事件而已。解決辦法也很簡單,把 e.stopImmediatePropagation() 換成 element.onclick = null 就可以了。
當然,目前這隻能防護 onclick,而現實中有太多的內聯事件。滑鼠、鍵盤、觸屏、網路狀態等等,不同瀏覽器支援的事件也不一樣,甚至還有私有事件,難道都要事先逐一列出並且都捕獲嗎?是的,可以都捕獲,但不必事先都列出來。
因為我們監聽的是 document 物件,瀏覽器所有內聯事件都對應著 document.onxxx 的屬性,因此只需執行時遍歷一下 document 物件,即可獲得所有的事件名。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
<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> |
現在,無論頁面中哪個元素觸發哪個內聯事件,都能預先被我們捕獲,並根據策略可進可退了。
效能優化
或許有些事件沒有必要捕獲,例如視訊播放、音量調節等,但就算全都捕捉也耗不了多少時間,基本都在 1ms 左右。
當然,註冊事件本來就花不了多少時間,真正的耗費都算在回撥上了。儘管大多數事件觸發都不頻繁,額外的掃描可以忽律不計。但和滑鼠移動相關的事件那就不容忽視了,因此得考慮效能優化。
顯然,內聯事件程式碼在執行過程中幾乎不可能發生變化。使用內聯事件大多為了簡單,如果還要在執行時 setAttribute 去改變內聯程式碼,完全就是不可理喻的。因此,我們只需對某個元素的特定事件,掃描一次就可以了。之後根據標誌,即可直接跳過。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
<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> |
這樣,之後的掃描僅僅是判斷一下目標物件中的標記而已。即使瘋狂晃動滑鼠,CPU 使用率也都忽略不計了。
到此,在 XSS 內聯事件這塊,我們已實現主動防禦。
對於有著大量字元,或者出現類似 String.fromCharCode,$.getScript 這類典型 XSS 程式碼的,完全可以將其攔截;發現有 alert(/xss/),alert(123) 這些測試程式碼,可以暫時放行,並將日誌傳送到後臺,確定是否能夠復現。
如果復現,說明已有人發現 XSS 併成功注入了,但還沒大規模開始利用。程式猿們趕緊第一時間修 BUG 吧,讓黑客忙活一陣子後發現漏洞已經修復了:)
字元策略的缺陷
但是,光靠程式碼字串來判斷,還是會有疏漏的。尤其是黑客們知道有這麼個玩意存在,會更加小心了。把程式碼轉義用以躲避關鍵字,並將字元儲存在其他地方,以躲過長度檢測,即可完全繞過我們的監控了:
1 |
<img src="*" onerror="window['ev'+'al'](this.align)" align="alert('a mass of code...')"> |
因此,我們不僅需要分析關鍵字。在回撥執行時,還需監控 eval、setTimeout(‘…’) 等這類能解析程式碼的函式被呼叫。
不過,通常不會注入太多的程式碼,而是直接引入一個外部指令碼,既簡單又靠譜,並且能實時修改攻擊內容:
1 |
<img src="*" onerror="$['get'+'Script'](...)"> |
下一篇將討論,如何攔截可疑的外部模組。