Cross-Site Request Forgery (CSRF, CWE-352): Funktionsweise und Schutz

Kernkonzepte & Begriffe

Umgebungs-Zugangsdaten

Browser hängen Cookies und HTTP-Authentifizierung an Requests für eine Website, egal welche Seite sie ausgelöst hat. Ein Request von evil.example an app.example trägt weiterhin das Sitzungscookie von app.example, sofern das SameSite-Attribut des Cookies das nicht verhindert.

SameSite-Attribut des Cookies

Strict hält das Cookie bei jedem websiteübergreifenden Request zurück, Lax sendet es nur bei GET-Navigationen auf oberster Ebene, und None sendet es immer (und verlangt Secure). Chromium behandelt Cookies ohne Attribut als Lax, Firefox und Safari nicht, und „same-site“ umfasst auch benachbarte Subdomains.

Synchronizer-Token

Ein an die Sitzung gebundener Zufallswert, den der Server in jedes Formular oder jede Seite schreibt und bei jedem unsicheren Request verlangt. Eine fremde Website kann ihn nicht lesen und daher keinen gültigen Request fälschen. CSRFProtect aus Flask-WTF gibt ihn über csrf_token() aus und prüft das Feld csrf_token oder den Header X-CSRFToken.

Fetch Metadata (Sec-Fetch-Site)

Moderne Browser senden bei jedem Request Sec-Fetch-Site: cross-site, same-site, same-origin oder none, und Seiten können den Header nicht fälschen. Wer unsichere Methoden ablehnt, die nicht same-origin sind, blockiert CSRF mit einer einzigen serverseitigen Prüfung.

Zustandsänderung per GET

Eine Route, die Daten per GET ändert, lässt sich mit einem <img>-Tag oder einem Link auslösen, und SameSite=Lax sendet das Cookie bei GET-Navigationen auf oberster Ebene weiterhin mit. request.values liest neben dem Formular-Body auch den Query-String.

Schritt-für-Schritt Angriffsablauf

Quellcode: Verwundbar vs. Sicher

# app.py: das Sitzungscookie ist der einzige Beleg, dass der Nutzer es wollte
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 funktioniert auch, und request.values liest auch den Query-String
@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: Token, SameSite-Cookie und Fetch Metadata zusammen
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",
)
# jeder POST braucht csrf_token; Formulare rendern {{ csrf_token() }}, fetch() sendet X-CSRFToken
csrf = CSRFProtect(app)


# von fremden Websites ausgelöste Schreibzugriffe werden vor der Route abgelehnt
@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)


# nur POST, Daten aus dem Formular-Body
@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"}

Checkliste für Engineering & Systemsicherheit

• Zustand nur per POST, PUT, PATCH oder DELETE ändern und Formulardaten aus dem Body lesen (request.form), nie aus request.values oder dem Query-String.
• Die CSRF-Middleware des Frameworks für die ganze App aktivieren (CSRFProtect, Djangos CsrfViewMiddleware, csrf() in Spring Security) und das Token in jedes Formular und jeden AJAX-Request aufnehmen.
• Sitzungscookies auf Secure, HttpOnly und SameSite=Lax oder Strict setzen; SameSite=None nur für Cookies verwenden, die in websiteübergreifenden iframes funktionieren müssen.
• Unsichere Requests ablehnen, deren Header Sec-Fetch-Site den Wert cross-site oder same-site hat.
• Einen CI-Test ergänzen, der jede zustandsändernde Route ohne Token aufruft und 400 oder 403 erwartet.

Quellen

• 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