本文详解 CSRF防御的三层方案及常见误区：第一层使用 SameSite Cookie 结合 Secure/HttpOnly 属性阻止跨站携带，但防范同一主域下的恶意子域名攻击。第二层通过前后端双验证 CSRF Token， Neither 与 Session 绑定依赖 Token随机性，需配合强校验（Timing Safe Equal）。第三层基于可信 Origin 或 Referer 的白名单校验，要求精确匹配而非模糊判断。防御中需避免单独依赖某层，强调 Token 更新与密钥签名的结合，并指出需匹配 HTTP Methods(POST/PUT/PATCH/DELETE)进行校验。重点提醒 XSS 攻击可能绕过 CSRF 防护，因此必须同时实施输入过滤和 Content Security Policy。常见误区包括频繁更换 Token 增加复杂度、错误使用 Referer 字符串前缀、将 CORS 白名单等同于 Origin 校验。最终推荐采用 Cookie 属性限制+前后端 Token 校验+精确 Origin 或 Referer 匹配的三重防护方案。

CSRF 攻击利用浏览器自动携带登录 Cookie特性，无需窃取凭证即可假冒用户操作。核心条件为：用户已在目标网站登录且 Cookie 未设置 SameSite=Strict/None；服务端仅验证登录状态不校验请求源或随机验证 Token；攻击者能构造符合接口要求的请求格式。 防御需多重加固：1. Cookie 添加 SameSite=Strict; Secure; HttpOnly 防止跨域脚本读取，但后者仍无法阻止自动携带，需配合 2. CSRF Token 机制（双向验证） 3. 严格验证请求来源和随机参数。特别需注意：JSON 接口若依赖前端传入 Token 仍存在风险，GET 请求不可用于修改状态（如删除账户），而 POST 可exploit但需结合防治措施。实验表明，同主机的跨端口请求可有效突破 CORS 限制，说明需要区分 Origin 和 SameSite 的边界保护。攻击成功后用户不会察觉异常，损失可能需数日才发现。

用户登录后，服务端生成Session并通过Cookie传递给浏览器，浏览器会自动携带该Cookie与后续请求。此机制易被CSRF攻击利用。防御需多维度设置：HttpOnly防止XSS窃取Cookie值，但无法阻止攻击通过网络劫持成功；SameSite=lax可限制部分跨站请求但需结合Csrf Token；Secure强制HTTPS传输。推荐配置__Host前缀并设置Path=/和Secure，将Cookie限定当前主机的根路径。需注意SameSite=lax仍可能因同站漏洞导致 CSRF，且 scratches 教程的复查验证步骤对完整性至关重要。常见误区：HttpOnly不阻止浏览器自动发送，SameSite无法替代服务端Csrf验证。需结合Session管理，主动更新权限或注销异常会话。