跨站请求伪造（CSRF，CWE-352）：原理与防御方法

核心概念与专有名词

环境凭据

无论是哪个页面发起的请求，浏览器都会给发往某个网站的请求附上 Cookie 和 HTTP 认证。从 evil.example 发往 app.example 的请求仍会带上 app.example 的会话 Cookie，除非该 Cookie 的 SameSite 属性阻止了它。

Cookie 的 SameSite 属性

Strict 在所有跨站请求中都不发送 Cookie，Lax 只在顶层 GET 导航时发送，None 总是发送（并且要求 Secure）。Chromium 把没有该属性的 Cookie 当作 Lax，Firefox 和 Safari 不会，而且“同站”还包括相邻的子域名。

同步令牌

与会话绑定的随机值，服务器把它放进每个表单或页面，并在每个不安全的请求中要求它。其他网站读不到它，因此无法伪造有效请求。Flask-WTF 的 CSRFProtect 通过 csrf_token() 生成它，并检查 csrf_token 字段或 X-CSRFToken 请求头。

Fetch Metadata（Sec-Fetch-Site）

现代浏览器在每个请求中都会发送 Sec-Fetch-Site: cross-site、same-site、same-origin 或 none，页面无法伪造它。拒绝非 same-origin 的不安全方法，就能用一次服务器端检查挡住 CSRF。

用 GET 修改状态

用 GET 修改数据的路由可以被一个 <img> 标签或链接触发，而 SameSite=Lax 在顶层 GET 导航时仍会发送 Cookie。读取 request.values 除了表单主体还会接受查询字符串。

攻击执行流程分解

源代码对比：漏洞与安全实现

# app.py：会话 Cookie 是用户本意的唯一证明
import os

from flask import Flask, abort, request, session

from .db import db

app = Flask(__name__)
app.config.update(
    SECRET_KEY=os.environ["FLASK_SECRET_KEY"],
    SESSION_COOKIE_SECURE=True,
    SESSION_COOKIE_SAMESITE="None",
)


# GET 也能用，而且 request.values 还会读取查询字符串
@app.route("/account/email", methods=["GET", "POST"])
def change_email():
    user_id = session.get("user_id")
    if user_id is None:
        abort(401)
    db.execute("UPDATE users SET email = ? WHERE id = ?", (request.values["email"], user_id))
    return {"status": "ok"}

# app.py：令牌、SameSite Cookie 和 Fetch Metadata 一起使用
import os

from flask import Flask, abort, request, session
from flask_wtf.csrf import CSRFProtect

from .db import db

app = Flask(__name__)
app.config.update(
    SECRET_KEY=os.environ["FLASK_SECRET_KEY"],
    SESSION_COOKIE_SECURE=True,
    SESSION_COOKIE_HTTPONLY=True,
    SESSION_COOKIE_SAMESITE="Lax",
)
# 每个 POST 都需要 csrf_token；表单渲染 {{ csrf_token() }}，fetch() 发送 X-CSRFToken
csrf = CSRFProtect(app)


# 由其他网站发起的写操作在执行路由前就被拒绝
@app.before_request
def reject_cross_site_writes():
    if request.method not in ("GET", "HEAD", "OPTIONS"):
        if request.headers.get("Sec-Fetch-Site", "same-origin") not in ("same-origin", "none"):
            abort(403)


# 只接受 POST，数据来自表单主体
@app.post("/account/email")
def change_email():
    user_id = session.get("user_id")
    if user_id is None:
        abort(401)
    db.execute("UPDATE users SET email = ? WHERE id = ?", (request.form["email"], user_id))
    return {"status": "ok"}

工程与系统安全加固清单

• 只用 POST、PUT、PATCH 或 DELETE 修改状态，并从请求主体（request.form）读取表单数据，绝不从 request.values 或查询字符串读取。
• 为整个应用启用框架的 CSRF 中间件（CSRFProtect、Django 的 CsrfViewMiddleware、Spring Security 的 csrf()），并在每个表单和 AJAX 请求中带上令牌。
• 把会话 Cookie 设为 Secure、HttpOnly 和 SameSite=Lax 或 Strict；只有必须在跨站 iframe 中使用的 Cookie 才用 SameSite=None。
• 拒绝 Sec-Fetch-Site 请求头为 cross-site 或 same-site 的不安全请求。
• 在 CI 中添加测试，对每个修改状态的路由发送不带令牌的请求，并期望得到 400 或 403。

参考来源

• CWE-352: Cross-Site Request Forgery (CSRF)
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet
• Flask-WTF — CSRF Protection
• MDN — Sec-Fetch-Site
• MDN — Set-Cookie: SameSite