Cross-Site Request Forgery (CSRF, CWE-352) : fonctionnement et prévention

Concepts Clés et Termes

Identifiants ambiants

Les navigateurs joignent cookies et authentification HTTP aux requêtes vers un site quelle que soit la page qui les a déclenchées. Une requête de evil.example vers app.example porte encore le cookie de session de app.example, sauf si l'attribut SameSite du cookie l'en empêche.

Attribut SameSite du cookie

Strict retient le cookie sur toute requête intersite, Lax ne l'envoie que lors des navigations GET de premier niveau et None l'envoie toujours (et exige Secure). Chromium traite les cookies sans attribut comme Lax ; Firefox et Safari non, et « même site » inclut aussi les sous-domaines voisins.

Jeton synchroniseur

Une valeur aléatoire liée à la session que le serveur place dans chaque formulaire ou page et exige sur chaque requête non sûre. Un autre site ne peut pas la lire, donc ne peut pas forger de requête valide. Le CSRFProtect de Flask-WTF l'émet via csrf_token() et vérifie le champ csrf_token ou l'en-tête X-CSRFToken.

Fetch Metadata (Sec-Fetch-Site)

Les navigateurs modernes envoient Sec-Fetch-Site: cross-site, same-site, same-origin ou none sur chaque requête, et les pages ne peuvent pas le falsifier. Refuser les méthodes non sûres qui ne sont pas same-origin bloque le CSRF en un seul contrôle côté serveur.

Changement d'état en GET

Une route qui modifie des données en GET peut être déclenchée par une balise <img> ou un lien, et SameSite=Lax envoie encore le cookie lors des navigations GET de premier niveau. Lire request.values accepte la query string en plus du corps du formulaire.

Déroulement de l'Attaque Étape par Étape

Code Source : Vulnérable vs Sécurisé

# app.py : le cookie de session est la seule preuve que l'utilisateur l'a voulu
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 marche aussi, et request.values lit aussi la 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 : jeton, cookie SameSite et Fetch Metadata ensemble
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",
)
# chaque POST exige csrf_token ; les formulaires affichent {{ csrf_token() }}, fetch() envoie X-CSRFToken
csrf = CSRFProtect(app)


# les écritures déclenchées par un autre site sont refusées avant la route
@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 uniquement, données issues du corps du formulaire
@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"}

Liste de Contrôle de Sécurité pour l'Ingénierie

• Ne modifiez l'état qu'en POST, PUT, PATCH ou DELETE, et lisez les données du formulaire dans le corps (request.form), jamais dans request.values ou la query string.
• Activez le middleware CSRF du framework pour toute l'application (CSRFProtect, CsrfViewMiddleware de Django, csrf() de Spring Security) et incluez le jeton dans chaque formulaire et requête AJAX.
• Configurez les cookies de session en Secure, HttpOnly et SameSite=Lax ou Strict ; réservez SameSite=None aux cookies qui doivent fonctionner dans des iframes intersites.
• Refusez les requêtes non sûres dont l'en-tête Sec-Fetch-Site vaut cross-site ou same-site.
• Ajoutez un test CI qui envoie à chaque route modifiant l'état une requête sans jeton et attend 400 ou 403.

Sources

• 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