面试题手册

验证 CSRF 防护有效性，核心就三步：构造跨站请求 → 观察是否被拦截 → 确认合法请求不受影响。针对每种防护手段有不同的测试思路：CSRF Token：删掉请求中的 token 字段，发 POST 应返回 403；换随机字符串也应被拒；用正确 token 才能通过。Token 还要验证不可预测性——连续请求 100 次，返回值应各不相同。SameSite Cookie：检查响应头 Set-Cookie 是否包含 SameSite=Strict 或 Lax。从第三方站点发请求，Strict 模式下 Cookie 不应被携带。Referer/Origin 校验：请求不带 Referer、或伪造为外部域名，服务端应拒绝；只有同域来源才放行。实操方法手动测试：写一个独立 HTML 页面，包含指向目标接口的隐藏表单，浏览器打开后自动提交。请求成功则说明无防护。自动化工具：Burp Suite 的 CSRF PoC 生成功能可一键构造攻击页面；OWASP ZAP 主动扫描会自动检测 CSRF 漏洞。单元测试：用 Jest/Supertest 模拟不带 token 的 POST 请求，断言返回 403。覆盖三个场景：缺 token、无效 token、有效 token。追问：Token 被 XSS 泄露了怎么办？CSRF Token 防护的前提是攻击者拿不到 token。站点存在 XSS 时，攻击者可读取 token 值，防护即失效。因此 CSRF 防护必须和 XSS 防御配合。替代方案是双重提交 Cookie——请求参数和 Cookie 各放一份 token，服务端比对一致即可，攻击者无法读取跨域 Cookie。追问：前后端分离项目怎么处理？SPA 架构下，token 通过接口获取后存前端，请求时放在自定义 Header（如 X-CSRF-Token）。跨站请求无法自动附加自定义 Header，浏览器同源策略限制了跨域请求自定义 Header 的发送，所以 SPA + 自定义 Header 比传统表单隐藏字段更安全。