由于web前端项目的特殊性,所有的前端代码基本上是开源的,这就意味着,访问者可以无条件的查看所有的代码,甚至进行调试,弄清项目的业务逻辑,这样,漏洞挖掘者就可以很方便的找出网站的漏洞进行攻击。
出于安全的目的,前端会对代码进行各种压缩打包,混淆等,增加阅读代码的难度,但对于调试,似乎很多人并没有引起应有的重视,下面会介绍一种比较基础的方法,用于阻止网站访问者对项目进行调试。
我们都知道,在js代码中加入debuger之后,网站打开开发者模式之后就会在debuger的地方触发断点进行调试,而如果不是出于调试模式下,debugger则会被忽略,利用浏览器的这个特性,我们可以编写一下这行代码
(function noDebuger(){
function testDebuger(){
var d=new Date();
debugger;
if(new Date()-d>10){
document.body.innerHTML='<div>年轻人,不要太好奇</div>';
return true;
}
return false;
}
function start(){
while(testDebuger()){
testDebuger();
}
}
if(!testDebuger()) {
window.onblur = function(){
setTimeout(function(){
start();
},500)
}
}
else{
start();
}
})();
我们编写了一个匿名函数并自执行,在testDebuger方法中,我们在debuger前后分别获取了两个时间,并对比这两个时间差,如果debugger之前前后的时间差超过了10毫秒,我们就判定当前用户打开了开发者工具,这个时候我们就可以执行一些反制措施,然后返回检测状态。对于start函数,我们写死了一个循环,当我们检测到用户打开了调试,则会不断的去执行testDebuger,这个时候代码就会不断的命中断点,导致访问者无法调试。
那么接下来,就是何时执行start函数的问题了,理论上我们可以进入网站时就直接执行start函数,但这样会在项目中无限执行testDebuger,这样对性能消耗太大,站在性能优化的角度上,我们在后面的代码做了一些优化,一开始我们只执行一次testDebuger,当检测不到调试时,我们给onblur事件添加一个方法,只有当页面onblur时,我们就会开始执行start,这样,用户一旦打开了开发者工具,则必然触发onblur,这个时候反调试功能触发,而如果一开始就检测到了调试模式,那么就是用户已经开好开发者工具等着调试了,这个时候直接执行start,就无所谓了。这样,就能在不影响性能的情况下,达到反调试的目的。
当然,这个方法也只能是增加调试的难度,防君子,不防小人,防御攻击还是得从多个方面下手