XSS 前端防火墙 —— 天衣无缝的防护
到目前為止，我們防護的深度已經差不多，但廣度還有所欠缺。
例如，我們的屬性鉤子只考慮了 setAttribute，卻忽視還有類似的 setAttributeNode。盡管從來不用這方法，但并不意味人家不能使用。
例如，創建元素通常都是 createElement，事實上 createElementNS 同樣也可以。甚至還可以利用現成的元素 cloneNode，也能達到目的。因此，這些都是邊緣方法都是值得考慮的。
下面我們對之前討論過的監控點，進行逐一審核。
內聯事件執行 eval
在第一篇文章結尾談到，在執行回調的時候，最好能監控 eval，setTimeout('...') 這些能夠解析代碼的函數，以防止執行儲存在其他地方的 XSS 代碼。
先來列舉下這類函數：
-
eval
-
setTimeout(String) / setInterval(String)
-
Function
-
execScript / setImmediate(String)
事實上，利用上一篇的鉤子技術，完全可以把它們都監控起來。但現實并沒有我們想象的那樣簡單。
Function 重寫有意義嗎
Function 是一個全局變量，重寫 window.Function 理論上完全可行吧。
var raw_fn = window.Function;window.Function = function() { alert('調用Function'); return raw_fn.apply(this, arguments); }; var add = Function('a', 'b', 'return a+b'); console.log( add(1, 2) );重寫確實可行。但現實卻是不堪一擊的：因為所有函數都是 Function 類的實例，所以訪問任何一個函數的 constructor 即可得到原始的 Function。
例如 alert.constructor，就可以繞過我們的鉤子。甚至可以用匿名函數：
(function(){}).constructor所以，Function 是永遠鉤不住的。
額外的執行方法
就算不用這類函數，仍有相當多的辦法執行字符串，例如：
-
創建腳本，innerHTML = 代碼
-
創建腳本，路徑 =?data:代碼
-
創建框架，路徑 =?javascript:代碼
-
......
看來，想完全把類似 eval 的行為監控起來，是不現實的。不過作為預警，我們只監控 eval，setTimeout/Interval 也就足夠了。
可疑模塊攔截
第二篇談了站外模塊的攔截。之所以稱之『模塊』而不是『腳本』，并非只有腳本元素才具備執行能力。框架頁、插件都是可以運行代碼的。
可執行元素
我們列舉下，能執行遠程模塊的元素：
- 腳本
- 框架
- 插件（Flash）
- 插件（其他）
這些元素的路徑屬性，都應該作為排查的對象。
不過，有這么個元素的存在，可能導致我們的路徑檢測失效，它就是：
<base href="...">它能重定義頁面的相對路徑，顯然是不容忽視的。
事實上，除了使用元素來執行站外模塊，還可以使用網絡通信，獲得站外的腳本代碼，然后再調用 eval 執行：
AJAX
目前主流瀏覽器都支持跨域請求，只要服務端允許就可以。因此，我們需監控 XMLHttpRequest::open 方法。如果請求的是站外地址，就得做策略匹配。不通過則放棄向上調用，或者拋出一個異常，或者給 XHR 產生一個 400 狀態。
WebSocket
WebSocket 和 XHR 類似，也能通過鉤子的方法進行監控。
不過，值得注意的是，WebSocket 并非是個函數，而是一個類。因此，在返回實例的時候，別忘了將 constructor 改成自己的鉤子，否則就會泄露原始接口：
var raw_class = window.WebSocket;window.WebSocket = function WebSocket(url, arg) { alert('WebSocket 請求：' + url); var ins = new raw_class(url, arg); // 切記 ins.constructor = WebSocket; return ins; }; var ws = new WebSocket('ws://127.0.0.1:1000');另外，因為它是一個類，所以不要忽略了靜態方法或屬性：
-
WebSocket.CONNECTING
-
WebSocket.OPEN
-
...
因此，還需將它們拷貝到鉤子上。
框架頁消息
HTML5 賦予了框架頁跨域通信的能力。如果沒有為框架元素建立白名單的話，攻擊者可以嵌入自己的框架頁面，然后將 XSS 代碼 postMessage 給主頁面，通過 eval 執行。
不過為了安全考慮，HTML5 在消息事件里保存了來源地址，以識別消息是哪個頁面發出的。
因為是個事件，我們可以使用第一篇文章里提到的方法，對其進行捕獲。每當有消息收到時，可以根據策略，決定是否阻止該事件的傳遞。
// 我們的防御系統 (function() {window.addEventListener('message', function(e) { if (confirm('發現來自[' + e.origin + ']的消息：\n\n' + e.data + '\n\n是否攔截？')) { e.stopImmediatePropagation(); } }, true); })(); window.addEventListener('message', function(e) { alert('收到:' + e.data) }) postMessage('hello', '*');Run
當然，如果配置了框架頁的白名單，就能完全避免這回事了。所以這項防御可以選擇性的開啟。
事件源
HTML5 新增了一個叫 EventSource 的接口。不過其用法與 WebSocket 非常相似，因此可以使用類似的鉤子進行防御。
到此，我們列舉了各種能執行遠程模塊的方式。事實上，對其防御并不難，難的是收集這些監控點，做到滴水不漏。
API 鉤子
對于動態創建的可執行模塊，我們通過屬性鉤子，來監控其遠程路徑。
創建元素的方法
這一節是針對 Chrome 的，因為它不支持原生訪問器。
-
createElement / createElementNS 無中生有
-
cloneNode 克隆現有
-
innerHTML / outerHTML 工廠創建
前兩種，通過鉤子程序很容易實現。
第三種，因為 inner/outerHTML 是元素的 property，而非 attribute。由于 Chrome 是無法獲取原生訪問器的，所以使用鉤子會導致無法調用上級接口。
再者，inner/outerHTML 傳進來的是字符串。標簽和屬性魚龍混雜，解析字符串肯定是不靠譜的。所以還得先調用原生 innerHTML 批量構建出節點，然后再掃描其中的元素。而這個過程中，節點掛載事件已經觸發了。
所以，無需考慮第三種情況。
你可能會有疑問，既然用節點掛載事件都能搞定，為什么還要前面的鉤子？其實，在第二篇文章?里已經詳細討論了，動態創建的腳本沒法被事件攔截，所以才用鉤子。
而通過 innerHTML 產生的腳本，是不會執行的！這個大家都聽說過吧。
修改屬性的訪問器
通過原型鏈的訪問器鉤子，可以直接監控特定元素的特定 property，完全不影響他人，所以效率非常高。剛才列舉了可以執行遠程模塊的元素，這些元素的路徑屬性，都得進行重寫訪問器。
當然 Chrome 可以忽略這節。
修改屬性的方法
開頭也提到了，除了 setAttribute 外，使用 setAttributeNode 也能設置屬性，甚至還有 setAttributeNS 版本的。
由于 setAttribute 是個經常調用的方法，因此鉤子程序必須做足夠的優化，將額外的檢測消耗降到最低。
新頁面環境
除了使用最簡單的框架，其實還有其他可以獲得新頁面的途徑。
彈窗
通過彈窗也能獲得新頁面環境，大家都知道。但是窗口關閉，也隨之銷毀了，難道還能使用嗎？不妨測試一下：
<style> .aa { color: red }</style> <button id="btn">POPUP</button> <script> btn.onclick = function() { var win = window.open(); var raw_fn = win.Element.prototype.setAttribute; win.close(); setTimeout(function() { console.log(raw_fn); raw_fn.call(btn, 'class', 'aa'); }, 1000); }; </script>Run
盡管會有瞬間的閃動，但從新窗口里獲取的變量確實被保留下來了，并且依然起作用。因為我們引用著它，所以即使窗口關閉，仍然不會對其內存回收的。
現實中，可以把點擊事件綁在 document 上，這樣用戶隨便點哪里都能觸發，以此獲得純凈的環境。
因此，我們還得把彈窗函數，也通過鉤子保護起來。
除了最常用的 window.open，其實還有：
-
showModalDialog
-
showModelessDialog
opener
如果當前網頁是從其他頁面點擊打開的，無論是彈窗還是超鏈接，window.opener 都記錄著來源頁的環境。
如果是來源頁和自己又是同源站點，甚至還能訪問到來源頁里面的變量。
這種情況相當常見。例如從帖子列表頁，點開一個帖子詳情頁，那么詳情頁是完全可以操控列表頁的。
要解決這個問題也不難，直接給 window.opener 注入防護程序不就可以了，就像對待新出現的框架頁那樣。
但是，window.opener 可能也有自己的 opener，一層層遞歸上去或許有很多。每個頁面也許又有自己的框架頁，因此防護 window.opener 可能會執行非常多的代碼。如果在初始化時就進行，或許會有性能問題。
事實上，這個冷門的屬性幾乎不怎么用到。所以不如做個延時策略：只有第一次訪問 opener 的時候，才對其進行防護。
我們將 window.opener 進行重寫，把它變成一個 getter 訪問器：
var raw_opener = window.opener; var scanned;window.__defineGetter__('opener', function() { if (!scanned) { installHook(raw_opener); scanned = true; } return raw_opener; });這樣，只要不訪問 opener，就不會觸發對它的防護，做到真正按需執行。
后記
關于防護監控點，也沒有一個完整的答案，能想到多少算多少，以后可以慢慢補充。
但是，裝了那么多的鉤子及事件，對頁面的性能影響有多大呢？
所以，我們還得開發一個測試控制臺，來跟蹤這套系統?？纯幢O控全開時，會對頁面產生多大影響。
轉載于:https://www.cnblogs.com/sunshq/p/4028884.html
總結
以上是生活随笔為你收集整理的XSS 前端防火墙 —— 天衣无缝的防护的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： zencart分类页每页显示产品数量自定
- 下一篇： poj1150