验证码能防 CSRF 吗？我这样用对不对？
最近在给登录接口加 CSRF 防护，听说加验证码可以防，但我试了下感觉不太对劲。前端提交表单时带上了用户输入的验证码，后端也校验了，但好像还是可能被 CSRF 攻击？是不是我理解错了？
我现在是这么做的：用户输入用户名、密码和验证码，一起 POST 到 /login，后端验证验证码是否正确。但 CSRF 攻击者根本看不到验证码图片，应该没法伪造请求吧？可同事说这不保险……
fetch('/login', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
username: 'test',
password: '123456',
captcha: userInputCaptcha // 用户手动输入的验证码
})
})- 1
回答
52浏览
Session绑定CSRF防护真的有效吗？我这样写对不对？
我在用 Express + EJS 做一个简单的表单提交功能，听说把 CSRF token 和 Session 绑定能防攻击，但我照着文档写了还是有点懵——后端生成的 token 存到 session...
- 1
回答
26浏览
Vue表单提交时如何同时实现CSRF防护和验证码验证？
在开发登录表单时，我需要同时处理CSRF防护和验证码验证。现在遇到的问题是：当用户刷新验证码时，CSRF令牌没有同步更新，导致表单提交时后端返回验证失败。我尝试在获取验证码接口里携带CSRF令牌，但发...
- 2
回答
23浏览
React表单提交如何防止CSRF攻击？隐藏字段没生效？
在React项目里做订单取消功能，用隐藏字段传CSRF令牌，但提交时后端返回403错误。代码是这样写的： function CancelOrderForm() { const [csrfToken, ...
- 1
回答
3浏览
前端如何配合后端实现 CSRF 的 Session 绑定验证？
我最近在做登录功能，后端说要用 Session 绑定的方式来防 CSRF，但我搞不太明白前端要怎么配合。是不是每次请求都要带一个 token？ 我看后端在登录成功后往 Session 里存了个 csr...
- 1
回答
10浏览
前端怎么安全地处理 CSRF Token？
我在做登录功能时，后端要求每次请求都要带 CSRF Token，但我把 token 存在 Cookie 里，又怕被 XSS 攻击偷走。试过用 HttpOnly 的 Cookie，但前端又读不到 tok...
- 2
回答
21浏览
HttpOnly 能防 CSRF 吗？我是不是搞混了概念？
最近在做登录功能，看到资料说要加 HttpOnly 防止 XSS 窃取 cookie，但我以为它也能防 CSRF，结果测试发现照样能被跨站请求伪造，是不是理解错了？ 比如我后端设置了 Set-Cook...
- 2
回答
22浏览
CSRF Token 刷新后前端怎么同步更新？
我在用 Axios 拦截器处理 CSRF Token 过期的情况，后端返回 419 时会刷新 token 并在响应头里带新的 XSRF-TOKEN。但我不确定怎么安全地把新 token 应用到后续请求...
- 1
回答
30浏览
Referer检查防CSRF真的可靠吗？为什么我设置了还是被绕过？
我们后端加了Referer检查来防CSRF，但测试时发现攻击者用空Referer或者同域跳转就能绕过。我前端也试过加一些header，但好像没用。是不是这种防护方式本身就不太靠谱？ 另外，我在页面里用...
- 1
回答
32浏览
前端如何配合后端做好CSRF防护？状态变更操作总被拦截怎么办？
我们项目里用的是 cookie + CSRF token 的方案，后端要求所有修改数据的请求（比如 POST、PUT）都必须带一个叫 X-CSRF-Token 的 header。但我发现每次提交表单时...
- 2
回答
28浏览
Session绑定CSRF Token后前端怎么正确发送？
我后端用Session存了CSRF Token，登录后返回给前端，但我每次提交表单时还是被拦截。是不是我发请求的方式不对？ 我试过把token放在header里，也试过放在body里，但都失败了。后端...
先说为什么能防：CSRF攻击的核心是攻击者诱导用户访问一个恶意页面，让浏览器自动发请求到你的服务器。由于同源策略，攻击者的页面是看不到你的验证码图片的，所以他没法把正确的验证码塞到请求里。这样服务器校验验证码时就会失败，攻击就被挡住了。
但问题在于你只保护了登录接口。CSRF攻击通常发生在用户登录之后，比如修改密码、转账、删除数据这些敏感操作。你如果只在登录页用验证码，那其他接口怎么办？总不能每个操作都让用户输验证码吧，用户会疯的。
另外，用验证码防CSRF还有个隐患：验证码必须是一次性的、绑定到用户session的。如果你实现时有什么漏洞（比如验证码存在cookie里、可以重复使用），那防护就形同虚设了。
更标准的做法是用CSRF Token。流程是这样的：用户访问页面时，服务器生成一个随机token存在session里，同时传给前端埋到表单或请求头里。提交请求时带上这个token，服务器校验token和session里的是否匹配。由于攻击者的页面拿不到这个token（同样受同源策略限制），所以伪造的请求会被拒绝。
简单说：验证码能防CSRF，但不是最佳方案。建议登录用验证码防暴力破解，其他敏感操作用CSRF Token。如果你非要只用验证码，那就确保每个请求都生成新验证码、绑定session、校验一次就失效。