前端如何防范点击劫持中的 Strokejacking 攻击？

Des.梦雅提问于 2026-03-14 20:14:22 阅读 62

安全

最近在做项目安全审计，听说了一种叫 Strokejacking 的点击劫持变种，说是攻击者通过透明覆盖层诱导用户在不知情下触发操作。我试着加了 X-Frame-Options 和 CSP 的 frame-ancestors，但不确定对这种基于 DOM 覆盖的攻击是否有效。

比如我现在有个按钮，担心被恶意页面用透明 iframe 盖住，用户以为点的是别的东西，其实触发了我的功能。我写了下面这段 CSS 试图防止元素被覆盖，但好像没啥用？是不是思路错了？

.protected-button {
  position: relative;
  z-index: 9999;
  pointer-events: auto;
}
/* 还试过加这个 */
body {
  -webkit-touch-callout: none;
  -webkit-user-select: none;
}

点击劫持

我来解答赞 8 收藏

反馈

1 条解答

宇文文婷 Lv1

X-Frame-Options 和 CSP 的 frame-ancestors 对 Strokejacking 没用，这两个是防 iframe 嵌入的，但攻击者不需要嵌入你的页面，他们可以在自己页面上放个透明层覆盖在伪造的按钮上，用户点的是攻击者做的假按钮，实际触发的是你页面的功能。

你写的那段 CSS 确实思路错了——z-index 这些是页面内部的层级控制，攻击者可不管你这套，他能在自己DOM里叠更高层级。

真正有用的防护就几招：

一是关键操作加二次确认。比如点删除、支付、转账这类敏感操作，弹个确认框让用户再点一次，攻击者总不能逼用户再点一次吧？

二是验证码或行为验证。图形验证码、滑动验证、点选验证这些，攻击者没法自动化模拟用户操作。

三是服务端校验。检查请求的来源、频率、上下文合不合理，比如正常的表单提交应该有正常的页面停留时间，如果刚打开页面1秒就提交，十有八九有问题。

四是用 Fetch Metadata 请求头。服务端检查 Sec-Fetch-Site、Sec-Fetch-Mode 这些头，可以识别是不是从可信页面发来的请求。

简单说，纯前端 CSS 防御这条路走不通，必须在业务逻辑层面加校验。敏感操作加确认框+验证码是最简单直接的做法，比折腾各种请求头有用多了。

2026-03-16 22:00