針對XSS漏洞的前端防火牆:天衣無縫的防護(1)

上一篇講解了鉤子程式的攻防實戰，並實現了一套對框架頁的監控方案，將防護作用到所有子頁面。 到目前為止，我們防護的深度已經差不多，但廣度還有所欠缺。 例如，我們的屬性鉤子只考慮了setAttribute，卻忽視還有類似的setAttributeNode。 儘管從來不用這方法，但並不意味人家不能使用。 例如，創建元素通常都是createElement，事實上createElementNS同樣也可以。 甚至還可以利用現成的元素cloneNode，也能達到目的。 因此，這些都是邊緣方法都是值得考慮的。 下面我們對之前討論過的監控點，進行逐一審核。 內聯事件執行 eval在第一篇文章結尾談到，在執行回檔的時候，最好能監控eval，setTimeout('...') 這些能夠解析代碼的函數，以防止執行儲存在其他地方的XSS代碼。 先來列舉下這類函數：evalsetTimeout(String) / setInterval(String)FunctionexecScript / setImmediate(String)事實上，利用上一篇的鉤子技術， 完全可以把它們都監控起來。 但現實並沒有我們想像的那樣簡單。 eval 重寫有問題嗎eval 不就是個函數，為什麼不可以重寫?varraw_fn=window.eval; window.eval=function(exp){ alert('執行eval:'+exp); returnraw_fn.apply(this,arguments); }; console.log(eval('1+1'));完全沒問題啊。 那是因為代碼太簡單了，下面這個 Demo 就可以看出山寨版 eval 的缺陷：(function(){ eval('vara=1'); }) (); alert(typeofa); Run按理說應該 undefined 才對，結果卻是 number。 區域變數都跑到全域上來了。 這是什麼情況?事實上，eval 並不是真正意義的函數，而是一個關鍵字! 1 2 3 4 下一頁>>查看全文 內容導航第 1 頁：內聯事件執行 eval 第 2 頁：Function 重寫有意義嗎 第 3 頁：框架頁消息 第 4 頁：修改屬性的訪問器 原文：針對XSS漏洞的前端防火牆:天衣無縫的防護(1) 返回網路安全首頁