讲解了钩子程序的攻防实战,并实现了一套对框架页的监控方案,将防护作用到所有子页面。
到目前为止,我们防护的深度已经差不多,但广度还有所欠缺。
例如,我们的属性钩子只考虑了 setAttribute,却忽视还有类似的 setAttributeNode。尽管从来不用这方法,但并不意味人家不能使用。
例如,创建元素通常都是 createElement,事实上 createElementNS 同样也可以。甚至还可以利用现成的元素 cloneNode,也能达到目的。因此,这些都是边缘方法都是值得考虑的。
下面我们对之前讨论过的监控点,进行逐一审核。
内联事件执行 eval
先来列举下这类函数:
eval
setTimeout(String) / setInterval(String)
Function
execScript / setImmediate(String)
事实上,利用上一篇的钩子技术,完全可以把它们都监控起来。但现实并没有我们想象的那样简单。
eval 重写有问题吗
eval 不就是个函数,为什么不可以重写?
var raw_fn = window.eval;
window.eval = function(exp) {
alert('执行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 并不是真正意义的函数,而是一个关键字!想了解详情请戳这里。
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。