Redirection par Header HTTP

Qu'est-ce que la Redirection par Header ?#

La redirection ouverte par header exploite la pratique courante d'utiliser des headers de requête HTTP — particulièrement Host et X-Forwarded-Host — pour construire des URLs absolues dans les réponses. Quand une application construit une URL de redirection comme https:// + request.headers["host"] + /reset?token=XYZ, un attaquant qui peut contrôler le header Host contrôle la destination de redirection.

La vulnérabilité relève de CWE-601 et OWASP A01:2021 (Broken Access Control). Elle diffère de la redirection par paramètre en ce que l'entrée malveillante arrive dans un header plutôt qu'un paramètre de requête — elle est invisible dans l'URL, et de nombreux contrôles de sécurité focalisés sur les URLs et règles WAF la manquent complètement.

L'impact le plus élevé : l'empoisonnement de reset de mot de passe. Un attaquant utilise l'injection de header Host pour empoisonner les liens de reset envoyés aux adresses email des victimes, puis intercepte le token de reset pour prendre le contrôle du compte.

Empoisonnement de Reset de Mot de Passe — Chaîne Étape par Étape#

L'empoisonnement de reset de mot de passe via header Host est le vecteur d'exploitation le plus impactant car il convertit une interaction réseau ponctuelle en prise de contrôle de compte persistante :

1. L'attaquant identifie un endpoint de reset de mot de passe qui envoie un email contenant un lien de reset construit depuis le header Host de la requête — ex : https://[Host]/reset?token=[TOKEN].
2. L'attaquant soumet une demande de reset pour l'email de la victime avec un Host: evil.com personnalisé (ou X-Forwarded-Host: evil.com). Aucune authentification requise — l'endpoint de reset est public.
3. L'application génère un token de reset pour le compte victime et envoie un email à la victime avec un lien de reset pointant vers https://evil.com/reset?token=TOKEN_VALIDE.
4. La victime clique sur le lien — le token est envoyé à evil.com. L'attaquant le logue.
5. L'attaquant réinitialise le mot de passe de la victime en envoyant POST /reset?token=TOKEN_VALIDE&new_password=mdp_attaquant au serveur légitime. Prise de contrôle du compte accomplie.

L'attaque est entièrement passive du point de vue de la victime : elle reçoit un email de reset d'apparence légitime depuis la bonne adresse d'expéditeur, clique sur un lien, et son compte est pris en charge — même si elle n'entre jamais d'identifiants sur le site de l'attaquant.

Chaîne d'Empoisonnement de Cache — De l'Individuel au Massif#

L'empoisonnement de cache web via X-Forwarded-Host fait évoluer l'attaque du ciblage d'un utilisateur à la compromission de tous les utilisateurs d'une ressource mise en cache :

1. L'attaquant identifie une page où la réponse inclut des URLs construites depuis X-Forwarded-Host (liens canoniques, sources JavaScript, endpoints API, ou URLs de redirection).
2. L'attaquant envoie une requête avec X-Forwarded-Host: evil.com et vérifie que la réponse inclut evil.com dans une URL.
3. L'attaquant vérifie la clé de cache — si le CDN/Varnish/Nginx n'inclut pas X-Forwarded-Host dans la clé de cache (courant dans les configurations CDN mal configurées), la réponse empoisonnée peut être mise en cache.
4. Les utilisateurs suivants demandant la même ressource reçoivent la réponse empoisonnée mise en cache. Leurs navigateurs chargent du JavaScript ou suivent des redirections depuis evil.com — du code contrôlé par l'attaquant s'exécute dans le contexte du domaine légitime.

Le rayon d'impact dépend du TTL de cache et du volume de trafic. Une réponse empoisonnée avec max-age=3600 servie sur un chemin à fort trafic peut affecter des milliers d'utilisateurs avant l'expiration du cache.

Vecteurs d'Injection de Header Additionnels#

Au-delà de Host et X-Forwarded-Host, plusieurs autres headers peuvent provoquer une injection de redirection selon le framework :

• Forwarded: host=evil.com (RFC 7239) — header proxy-forwarding moderne, certains frameworks le préfèrent à X-Forwarded-Host
• X-Original-URL: /admin — Symfony et certaines configurations Django utilisent ceci pour surcharger le chemin URL de la requête ; combiné avec une redirection, peut produire des valeurs Location contrôlées par l'attaquant
• X-Rewrite-URL — anciennes configurations IIS et Apache mod_rewrite ; impact similaire à X-Original-URL
• X-Forwarded-Server — moins courant, mais certains serveurs d'applications Java l'utilisent pour la construction d'URL
• Front-End-HTTPS: on — header Microsoft pour la détection de schéma ; si l'application l'utilise pour déterminer http:// vs https://, peut être abusé pour générer du contenu mixte

Mécanisme#

Le code côté serveur vulnérable :

# VULNÉRABLE Flask — construit l'URL de reset depuis le header Host
from flask import request
 
@app.route("/forgot-password", methods=["POST"])
def forgot_password():
    email = request.form["email"]
    token = generate_reset_token(email)
    # VULNÉRABLE : utilise request.host (contrôlé par l'attaquant)
    reset_url = f"https://{request.host}/reset?token={token}"
    send_email(email, f"Cliquez ici pour réinitialiser: {reset_url}")
    return "Email envoyé", 200

# Requête malveillante de l'attaquant
POST /forgot-password HTTP/1.1
Host: evil.com
Content-Type: application/x-www-form-urlencoded
 
email=victime@target.com
 
# La victime reçoit l'email :
# "Cliquez ici pour réinitialiser: https://evil.com/reset?token=TOKEN_VALIDE_ICI"

Variantes d'Attaque#

Empoisonnement de Cache via X-Forwarded-Host#

# L'attaquant envoie (suppose X-Forwarded-Host hors de la clé de cache) :
GET /home HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com
 
# Réponse vulnérable (mise en cache par CDN/Varnish) :
HTTP/1.1 200 OK
Cache-Control: max-age=3600
Content-Type: text/html
 
<script src="https://evil.com/app.js"></script>
<link rel="canonical" href="https://evil.com/home">

Si la clé de cache inclut uniquement Host (pas X-Forwarded-Host), cette réponse empoisonnée est servie à tous les utilisateurs suivants demandant /home depuis target.com. Leurs navigateurs chargent evil.com/app.js — JavaScript contrôlé par l'attaquant s'exécutant dans le contexte de target.com.

Exemples Réels#

CVE-2024-46452 — Plateforme similaire OpenCart (CVSS 8.1) Cette plateforme CMS utilisait le header HTTP Host directement dans la construction de l'email de réinitialisation de mot de passe. Les attaquants soumettaient des demandes de reset pour des comptes victimes avec Host: evil.com, causant l'email de reset à contenir https://evil.com/index.php?route=account/reset&code=TOKEN. Quand les victimes cliquaient, leurs tokens de reset étaient loggés sur evil.com. CVSS 8.1 (Élevé) reflète l'impact de prise de contrôle de compte complète.

CVE-2024-40686 — IBM SmartCloud Analytics (CVSS 6.5) IBM SmartCloud Analytics était vulnérable à l'injection de header Host causant une manipulation de cache et de redirection de session. L'application utilisait le header Host pour construire des URLs dans les réponses API et les redirections. Corrigé dans l'avis de sécurité IBM en codant en dur l'URL de base depuis la configuration.

Recherche PortSwigger — Empoisonnement de Reset de Mot de Passe La recherche de PortSwigger sur les attaques de header Host identifie l'empoisonnement de reset de mot de passe comme la vulnérabilité de header Host la plus couramment exploitée dans les applications réelles. Le pattern apparaît dans les frameworks PHP (où $_SERVER['HTTP_HOST'] est contrôlé par l'attaquant), Django (sans ALLOWED_HOSTS configuré), et Express.js (où req.hostname fait confiance aux headers proxy sans configuration trusted proxy).

Détection#

Test Manuel#

1. Installer l'extension Burp Suite Param Miner — elle fuzze automatiquement Host, X-Forwarded-Host et les headers connexes.
2. Naviguer vers l'endpoint de réinitialisation de mot de passe. Dans Burp Repeater, ajouter X-Forwarded-Host: VOTRE_URL_COLLABORATOR. Soumettre une réinitialisation pour un compte contrôlé.
3. Vérifier l'email de reset — contient-il votre URL Collaborator ? Si oui : empoisonnement de reset de mot de passe confirmé.
4. Utiliser Burp Collaborator pour vérifier si le serveur effectue des requêtes vers l'hôte injecté (confirmation OOB).

# Test de l'override Host
GET / HTTP/1.1
Host: canary.oast.fun
X-Forwarded-Host: canary.oast.fun

Détection Automatisée#

# Burp Param Miner — fuzzing de header Host
# Activer via Burp Extensions → Param Miner → "Guess headers"
 
# nuclei — templates d'injection de header Host
nuclei -u https://target.com -t http/misconfiguration/host-header-injection.yaml
 
# httpx — vérification de réflexion de header Host
echo "https://target.com" | httpx -H "Host: canary.oast.fun" -silent -match-string "canary.oast.fun"
 
# Test curl manuel pour réflexion X-Forwarded-Host
curl -sI -H "X-Forwarded-Host: canary.oast.fun" https://target.com/forgot-password | grep -i "location\|canary"

BreachVex détecte l'injection de header Host en envoyant des demandes de reset de mot de passe avec un host canary out-of-band unique dans X-Forwarded-Host et en surveillant les callbacks DNS/HTTP. Un finding confirmé nécessite que le serveur inclue le canary dans un header Location de redirection, ou que le canary out-of-band reçoive une requête HTTP originant du serveur (la simulation de clic sur email n'est pas nécessaire — un callback out-of-band suffit pour la confirmation).

Prévention#

Coder en Dur l'URL de Base depuis une Variable d'Environnement#

# Flask — BONNE PRATIQUE
import os
 
BASE_URL = os.environ["APP_BASE_URL"]  # ex: "https://app.example.com"
 
@app.route("/forgot-password", methods=["POST"])
def forgot_password():
    email = request.form["email"]
    token = generate_reset_token(email)
    # BONNE PRATIQUE : URL de base depuis l'environnement, jamais depuis les headers de requête
    reset_url = f"{BASE_URL}/reset?token={token}"
    send_email(email, f"Cliquez ici pour réinitialiser: {reset_url}")
    return "Email envoyé", 200

// Express.js — BONNE PRATIQUE
const BASE_URL = process.env.APP_BASE_URL;  // https://app.example.com
 
app.post("/forgot-password", async (req, res) => {
  const token = await createResetToken(req.body.email);
  // BONNE PRATIQUE : URL de base codée en dur — jamais req.hostname ni req.headers.host
  const resetUrl = `${BASE_URL}/reset/${token}`;
  await sendResetEmail(req.body.email, resetUrl);
  res.json({ success: true });
});

Enforcement ALLOWED_HOSTS Django#

# settings.py
ALLOWED_HOSTS = ["app.example.com", "www.example.com"]
# Django rejette les requêtes où Host n'est pas dans cette liste avec 400 Bad Request
# Prévient l'injection de header Host au niveau du framework

Nginx — Supprimer X-Forwarded-Host des Clients Non Fiables#

server {
    listen 443 ssl;
    server_name app.example.com;
 
    location / {
        # Remplacer X-Forwarded-Host par le nom de serveur validé
        # Prévient les clients injectant des valeurs X-Forwarded-Host arbitraires
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;  # Override avec valeur validée
        proxy_pass http://app_backend;
    }
}

Ressources#

• PortSwigger — HTTP Host Header Attacks
• OWASP Testing Guide — Host Header Injection
• CWE-601 : URL Redirection to Untrusted Site
• Extension Param Miner (Burp Suite)