建站
咨詢
售后
建站咨詢
新聞中心
上一篇講解了鉤子程序的攻防實戰(zhàn)，并實現了一套對框架頁的監(jiān)控方案，將防護作用到所有子頁面。
成都創(chuàng)新互聯公司服務項目包括雨花網站建設、雨花網站制作、雨花網頁制作以及雨花網絡營銷策劃等。多年來，我們專注于互聯網行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯網行業(yè)的解決方案，雨花網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到雨花省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
到目前為止，我們防護的深度已經差不多，但廣度還有所欠缺。
例如，我們的屬性鉤子只考慮了setAttribute，卻忽視還有類似的setAttributeNode。盡管從來不用這方法，但并不意味人家不能使用。
例如，創(chuàng)建元素通常都是createElement，事實上createElementNS同樣也可以。甚至還可以利用現成的元素cloneNode，也能達到目的。因此，這些都是邊緣方法都是值得考慮的。
下面我們對之前討論過的監(jiān)控點，進行逐一審核。
內聯事件執(zhí)行 eval
在第一篇文章結尾談到，在執(zhí)行回調的時候，最好能監(jiān)控eval，setTimeout('...') 這些能夠解析代碼的函數，以防止執(zhí)行儲存在其他地方的XSS代碼。
先來列舉下這類函數：
eval setTimeout(String) / setInterval(String) Function execScript / setImmediate(String)
事實上，利用上一篇的鉤子技術，完全可以把它們都監(jiān)控起來。但現實并沒有我們想象的那樣簡單。
eval 重寫有問題嗎
eval 不就是個函數，為什么不可以重寫?
- 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
按理說應該 undefined 才對，結果卻是 number。局部變量都跑到全局上來了。這是什么情況?事實上，eval 并不是真正意義的函數，而是一個關鍵字!#p#
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 是永遠鉤不住的。
額外的執(zhí)行方法
就算不用這類函數，仍有相當多的辦法執(zhí)行字符串，例如：
創(chuàng)建腳本，innerHTML = 代碼 創(chuàng)建腳本，路徑 = data:代碼 創(chuàng)建框架，路徑 = javascript:代碼 ......
看來，想完全把類似 eval 的行為監(jiān)控起來，是不現實的。不過作為預警，我們只監(jiān)控 eval，setTimeout/Interval 也就足夠了。
可疑模塊攔截
第二篇談了站外模塊的攔截。之所以稱之『模塊』而不是『腳本』，并非只有腳本元素才具備執(zhí)行能力?？蚣茼摗⒉寮际强梢赃\行代碼的。
可執(zhí)行元素
我們列舉下，能執(zhí)行遠程模塊的元素：
腳本
Run
盡管會有瞬間的閃動，但從新窗口里獲取的變量確實被保留下來了，并且依然起作用。因為我們引用著它，所以即使窗口關閉，仍然不會對其內存回收的。
現實中，可以把點擊事件綁在 document 上，這樣用戶隨便點哪里都能觸發(fā)，以此獲得純凈的環(huán)境。
因此，我們還得把彈窗函數，也通過鉤子保護起來。
除了最常用的 window.open，其實還有：
showModalDialog
showModelessDialog
opener
如果當前網頁是從其他頁面點擊打開的，無論是彈窗還是超鏈接，window.opener 都記錄著來源頁的環(huán)境。
如果是來源頁和自己又是同源站點，甚至還能訪問到來源頁里面的變量。
這種情況相當常見。例如從帖子列表頁，點開一個帖子詳情頁，那么詳情頁是完全可以操控列表頁的。
要解決這個問題也不難，直接給 window.opener 注入防護程序不就可以了，就像對待新出現的框架頁那樣。
但是，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í)行。
后記
關于防護監(jiān)控點，也沒有一個完整的答案，能想到多少算多少，以后可以慢慢補充。
但是，裝了那么多的鉤子及事件，對頁面的性能影響有多大呢?
所以，我們還得開發(fā)一個測試控制臺，來跟蹤這套系統(tǒng)?？纯幢O(jiān)控全開時，會對頁面產生多大影響。
文章題目：針對XSS漏洞的前端防火墻:天衣無縫的防護
URL地址：http://www.5511xx.com/article/cojijeg.html
