关于检测与拦截浏览器开发者工具注入Javascript代码的技术咨询

可以实现一定程度的检测，但无法做到100%绝对拦截，客户端环境的最终控制权在用户手中，攻防始终处于不对称状态。

可行的检测方案 #

• 开发者工具开启状态检测：可以通过debugger语句断点检测、控制台对象懒加载检测、窗口尺寸差值检测等方式判断用户是否打开了开发者工具，一旦检测到直接重载页面、清除敏感数据或者中断行情推送，是门槛最低的拦截方案。
• 全局环境变更检测：你提到的全局变量哈希校验思路是可行的。页面初始化完成后，先遍历window对象所有自有属性、document对象属性、内置原型链方法，生成基准哈希值，之后定时遍历比对，只要出现新增属性、原有核心方法（比如XMLHttpRequest.prototype.send、WebSocket.prototype.send、fetch等通信相关API）被篡改，就触发告警或重载。提前把业务代码产生的合法全局变更加入白名单即可规避误判。
  直接粘贴到开发者工具控制台运行的代码默认共享页面的全局执行上下文，这类注入带来的全局变更基本都可以被该方案捕捉。如果攻击者切换到控制台的隔离执行上下文，虽然可以避开全局检测，但这类上下文无法直接访问页面内的业务变量和数据，对数据窃取场景没有实际价值。
• 异常行为拦截：可以重写所有对外通信相关的API入口，校验请求目标是否在站点白名单范围内，非白名单的请求直接拦截并触发告警。你提到的Notification API、Serial API等也可以用同样的方式重写，禁止非业务逻辑的调用。
• 原生方法校验：通过Function.prototype.toString校验内置方法的源码，正常原生方法调用toString返回的是function xxx() { [native code] }，如果被注入代码篡改，输出内容会发生明显变化，很容易识别。

你提到的方案的注意事项 #

你设想的变量哈希校验方案有两个需要规避的问题：

一是检测相关的核心代码必须做混淆加密，并且放在页面最顶部优先执行，尽可能早的锁定内置方法的原始引用。如果攻击者先篡改了你用来做哈希计算、属性遍历的方法，整个检测逻辑会直接失效。
二是document.all对你的需求帮助不大，这个属性仅返回文档内所有DOM元素的集合，如果注入代码不修改DOM，只是监听数据、发起请求，document.all不会出现可识别的异常变化，检测重点还是要放在全局对象、通信API、内置方法的变更上。

最终防护建议 #

• 不要完全依赖前端检测，攻击者只要有足够的技术能力，总能找到绕过方案：比如直接修改浏览器内核、用中间人代理替换你的检测脚本、在定制化浏览器中关闭开发者工具检测开关等，都可以绕过所有前端防护逻辑。
• 核心防护要放在服务端实现：比如给每个账号的行情推送做速率限制、做异常行为风控，发现某个账号的请求频率异常、登录地异动、多设备同时登录等情况，直接触发二次验证或者中断服务，可靠性远高于前端检测。

内容的提问来源于stack exchange，提问作者André Dias