上一篇講解了鉤子程序的攻防實戰(zhàn)，并實現(xiàn)了一套對框架頁的監(jiān)控方案，將防護作用到所有子頁面。
到目前為止，我們防護的深度已經(jīng)差不多，但廣度還有所欠缺。
例如，我們的屬性鉤子只考慮了setAttribute，卻忽視還有類似的setAttributeNode。盡管從來不用這方法，但并不意味人家不能使用。
例如，創(chuàng)建元素通常都是createElement，事實上createElementNS同樣也可以。甚至還可以利用現(xiàn)成的元素cloneNode，也能達到目的。因此，這些都是邊緣方法都是值得考慮的。
下面我們對之前討論過的監(jiān)控點，進行逐一審核。
內(nèi)聯(lián)事件執(zhí)行 eval
在第一篇文章結(jié)尾談到，在執(zhí)行回調(diào)的時候，最好能監(jiān)控eval，setTimeout('...') 這些能夠解析代碼的函數(shù)，以防止執(zhí)行儲存在其他地方的XSS代碼。
先來列舉下這類函數(shù)：
eval
setTimeout(String) / setInterval(String)
Function
execScript / setImmediate(String)
事實上，利用上一篇的鉤子技術(shù)，完全可以把它們都監(jiān)控起來。但現(xiàn)實并沒有我們想象的那樣簡單。
eval 重寫有問題嗎
eval 不就是個函數(shù)，為什么不可以重寫?
var raw_fn = window.eval; window.eval = function(exp) { alert('執(zhí)行eval: ' + exp); return raw_fn.apply(this, arguments); }; console.log(eval('1+1'));
完全沒問題啊。那是因為代碼太簡單了，下面這個 Demo 就可以看出山寨版 eval 的缺陷：
(function() { eval('var a=1'); })(); alert(typeof a);
Run
按理說應(yīng)該 undefined 才對，結(jié)果卻是 number。局部變量都跑到全局上來了。這是什么情況?事實上，eval 并不是真正意義的函數(shù)，而是一個關(guān)鍵字!
Function 重寫有意義嗎
Function 是一個全局變量，重寫 window.Function 理論上完全可行吧。
var raw_fn = window.Function; window.Function = function() { alert('調(diào)用Function'); return raw_fn.apply(this, arguments); }; var add = Function('a', 'b', 'return a+b'); console.log( add(1, 2) );
重寫確實可行。但現(xiàn)實卻是不堪一擊的：因為所有函數(shù)都是 Function 類的實例，所以訪問任何一個函數(shù)的 constructor 即可得到原始的 Function。
例如 alert.constructor，就可以繞過我們的鉤子。甚至可以用匿名函數(shù)：
(function(){}).constructor
所以，F(xiàn)unction 是永遠鉤不住的。
額外的執(zhí)行方法
就算不用這類函數(shù)，仍有相當多的辦法執(zhí)行字符串，例如：
創(chuàng)建腳本，innerHTML = 代碼
創(chuàng)建腳本，路徑 = data:代碼
創(chuàng)建框架，路徑 = javascript:代碼
......
看來，想完全把類似 eval 的行為監(jiān)控起來，是不現(xiàn)實的。不過作為預警，我們只監(jiān)控 eval，setTimeout/Interval 也就足夠了。
可疑模塊攔截
第二篇談了站外模塊的攔截。之所以稱之『模塊』而不是『腳本』，并非只有腳本元素才具備執(zhí)行能力?？蚣茼?、插件都是可以運行代碼的。
可執(zhí)行元素
我們列舉下，能執(zhí)行遠程模塊的元素：
腳本
Run
盡管會有瞬間的閃動，但從新窗口里獲取的變量確實被保留下來了，并且依然起作用。因為我們引用著它，所以即使窗口關(guān)閉，仍然不會對其內(nèi)存回收的。
現(xiàn)實中，可以把點擊事件綁在 document 上，這樣用戶隨便點哪里都能觸發(fā)，以此獲得純凈的環(huán)境。
因此，我們還得把彈窗函數(shù)，也通過鉤子保護起來。
除了最常用的 window.open，其實還有：
showModalDialog
showModelessDialog
opener
如果當前網(wǎng)頁是從其他頁面點擊打開的，無論是彈窗還是超鏈接，window.opener 都記錄著來源頁的環(huán)境。
如果是來源頁和自己又是同源站點，甚至還能訪問到來源頁里面的變量。
這種情況相當常見。例如從帖子列表頁，點開一個帖子詳情頁，那么詳情頁是完全可以操控列表頁的。
要解決這個問題也不難，直接給 window.opener 注入防護程序不就可以了，就像對待新出現(xiàn)的框架頁那樣。
但是，window.opener 可能也有自己的 opener，一層層遞歸上去或許有很多。每個頁面也許又有自己的框架頁，因此防護 window.opener 可能會執(zhí)行非常多的代碼。如果在初始化時就進行，或許會有性能問題。
事實上，這個冷門的屬性幾乎不怎么用到。所以不如做個延時策略：只有第一次訪問 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，就不會觸發(fā)對它的防護，做到真正按需執(zhí)行。
后記
關(guān)于防護監(jiān)控點，也沒有一個完整的答案，能想到多少算多少，以后可以慢慢補充。
但是，裝了那么多的鉤子及事件，對頁面的性能影響有多大呢?
所以，我們還得開發(fā)一個測試控制臺，來跟蹤這套系統(tǒng)。看看監(jiān)控全開時，會對頁面產(chǎn)生多大影響。