17370845950

CSRF防护需服务端绑定、一次性/短时效、传输隔离三条件并存，Django/Flask默认防护存在AJAX、JSON接口等盲区，须前后端协同管控token生命周期与传输路径。

Python Web 项目中，CSRF（跨站请求伪造）不是“会不会发生”的问题，而是“什么时候被利用”的问题——只要应用依赖 Cookie 进行身份认证、又没对非 GET 请求做有效防护，攻击就可能成功。

为什么 Flask/Django 默认不完全免疫 CSRF？

Django 自带 csrf_token 模板标签和中间件，但仅对表单 POST 生效；AJAX 请求、JSON 接口、自定义 header 场景下容易遗漏验证。Flask 更是默认不提供 CSRF 防护，需手动集成 flask-wtf 或自行实现 token 管理。常见疏漏包括：

• 前端未在 AJAX 请求头中携带 X-CSRFToken（Django）或 X-CSRF-Token（Flask-WTF）
• 后端视图跳过 @csrf_protect 装饰器，或使用 csrf_exempt 过度宽松
• 登录/登出接口未启用 CSRF 保护（攻击者可静默触发登出或伪造登录）

CSRF Token 必须满足的三个条件

一个有效的 CSRF token 不是随便生成的字符串，它需要同时满足：

• 服务端绑定：与当前用户 session 或 user ID 强关联，不能全局复用
• 一次性或短时效：每次表单渲染应刷新 token，或设置 1–2 小时有效期，避免泄露后长期有效
• 传输隔离：token 存在 Cookie（HttpOnly=False）供 JS 读取，但绝不通过 URL 参数或 Referer 传递

绕过常见防护的典型手法

攻击者常利用开发习惯漏洞绕过防护：

• 利用 GET 请求修改状态（如 /api/user/delete?id=123），因 GET 默认不校验 CSRF
• 前端将 token 写死在 JS 变量里，导致所有用户共用同一 token
• API 接口接受 Content-Type: text/plain 或 application/json，但后端未检查 Origin 或未校验 token（浏览器同源策略不限制这类请求发送）

简单可靠的加固建议

不需要重写整个鉴权体系，从这几个点切入就能显著降低风险：

• Django 项目确保 MIDDLEWARE 中启用 django.middleware.csrf.CsrfViewMiddleware，并在所有状态变更视图上保留 ensure_csrf_cookie()（尤其含 AJAX 的页面）
• Flask 项目统一用 flask-wtf.CSRFProtect，配合 generate_csrf() 在模板中注入，并在 API 视图中调用 validate_csrf()
• 对纯 API 服务（如前后端分离项目），强制要求每个非 GET 请求携带 X-Requested-With: XMLHttpRequest 并校验 Origin 头（仅允许可信域名）
• 敏感操作（转账、改密、删资源）增加二次确认机制，如短信/邮箱验证码，不依赖单一 token

CSRF 防护不是加个装饰器就万事大吉，关键在 token 生命周期管理、传输路径控制和前后端协同。漏掉任意一环，都可能让防护形同虚设。