HTTP Request Smuggling : L'attaque invisible qui contourne vos protections

Introduction

Imaginez une attaque capable de contourner votre WAF, de voler les sessions d'autres utilisateurs, et de compromettre votre infrastructure, le tout sans déclencher la moindre alerte. Ce n'est pas de la science-fiction, c'est le HTTP Request Smuggling.

Cette technique d'attaque, redécouverte et perfectionnée ces dernières années par des chercheurs comme James Kettle de PortSwigger, exploite les incohérences entre serveurs frontaux (reverse proxies, load balancers, CDN) et serveurs backend dans leur interprétation des requêtes HTTP.

En 2024-2025, avec la multiplication des architectures distribuées et des CDN, cette vulnérabilité est plus pertinente que jamais. Et pourtant, elle reste méconnue de la plupart des équipes de développement.

Comment fonctionne le HTTP Request Smuggling ?

Le problème fondamental

Le protocole HTTP/1.1 permet deux méthodes pour définir la longueur d'une requête :

Content-Length (CL) : Spécifie la taille exacte du corps en octets
Transfer-Encoding: chunked (TE) : Le corps est envoyé en morceaux, terminé par un chunk de taille 0

La RFC 2616 stipule que si les deux headers sont présents, Transfer-Encoding doit primer. Mais dans la pratique ? Chaque serveur implémente cette règle différemment.

Les variantes d'attaque

CL.TE (Content-Length puis Transfer-Encoding)

Le frontend utilise Content-Length, le backend utilise Transfer-Encoding.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

Le frontend lit 13 octets et transmet tout. Le backend voit le chunk 0\r\n\r\n comme fin de requête, et SMUGGLED devient le début d'une nouvelle requête.

TE.CL (Transfer-Encoding puis Content-Length)

Le frontend utilise Transfer-Encoding, le backend utilise Content-Length.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

Le frontend traite les chunks et transmet. Le backend ne lit que 3 octets (8\r\n), laissant SMUGGLED\r\n0\r\n\r\n en attente pour la prochaine requête.

TE.TE (Obfuscation du Transfer-Encoding)

Les deux serveurs supportent Transfer-Encoding, mais l'un peut être trompé par une obfuscation :

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding: chunked
Transfer-encoding: chunked

Transfer-Encoding: chunked
Transfer-Encoding : chunked

Transfer-Encoding: chunked,identity

Scénarios d'exploitation réels en 2025

1. Bypass de WAF et contrôles de sécurité

Contexte : Une application protégée par Cloudflare/AWS WAF bloque les requêtes contenant des patterns malveillants.

Attaque :

POST / HTTP/1.1
Host: target.com
Content-Length: 56
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target.com
X-Ignore: X

La requête vers /admin contourne le WAF car elle n'est jamais analysée comme une requête distincte par le frontend.

Impact réel : En 2024, cette technique a permis de contourner les protections de plusieurs plateformes SaaS majeures pour accéder à des endpoints d'administration.

2. Vol de sessions utilisateur (Request Hijacking)

Contexte : L'attaquant "empoisonne" le pipeline de requêtes pour capturer la requête d'un autre utilisateur.

La prochaine requête d'un utilisateur légitime sera interprétée comme le corps de la requête GET vers le serveur de l'attaquant, exposant ses cookies, tokens, et headers d'authentification.

3. Cache Poisoning via Smuggling

Contexte : Un CDN cache les réponses basées sur l'URL.

L'attaquant peut faire cacher une réponse malveillante pour un fichier JavaScript légitime, infectant tous les visiteurs suivants avec du code malveillant.

4. Exploitation des architectures microservices

Contexte moderne : API Gateway (Kong, AWS API Gateway) → Load Balancer → Services backend

Les architectures cloud natives multiplient les points d'interprétation HTTP, augmentant la surface d'attaque.

Client → CloudFront → ALB → Nginx → Application
         (TE)         (CL)   (TE)      (CL)

Chaque transition est un vecteur potentiel de smuggling.

Détection : Comment identifier cette vulnérabilité ?

Technique de détection par timing

Test CL.TE :

POST / HTTP/1.1
Host: target.com
Content-Length: 4
Transfer-Encoding: chunked

1
Z
Q

Si le serveur est vulnérable CL.TE, il attend le prochain chunk → timeout observable.

Test TE.CL :

POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked

0

X

Si vulnérable TE.CL, le X corrompt la prochaine requête → erreur sur la requête suivante.

Outils de détection

Burp Suite Pro : Extension "HTTP Request Smuggler" de James Kettle
smuggler.py : Outil open-source de détection automatisée
h2csmuggler : Pour les variantes HTTP/2 → HTTP/1.1 downgrade

HTTP/2 Smuggling : La nouvelle frontière

H2.CL et H2.TE

HTTP/2 devait éliminer le smuggling grâce à son framing binaire. Mais quand un frontend HTTP/2 traduit vers un backend HTTP/1.1, de nouvelles vulnérabilités apparaissent.

Le frontend HTTP/2 ignore le corps (longueur = framing), mais le backend HTTP/1.1 voit deux requêtes.

Cas réel : CVE-2023-25950 (HAProxy)

HAProxy, utilisé par des millions de sites, était vulnérable au smuggling via des headers HTTP/2 malformés, permettant de contourner les ACL.

Correction et prévention

1. Configuration serveur

Nginx :

# Rejeter les requêtes ambiguës
proxy_http_version 1.1;
proxy_request_buffering on;

# Normaliser les headers
proxy_set_header Transfer-Encoding "";

HAProxy :

defaults
    option http-buffer-request
    option httpchk

Apache :

# Activer le mode strict
HttpProtocolOptions Strict

2. Architecture

Uniformiser les serveurs : Utilisez la même stack partout si possible
HTTP/2 end-to-end : Évitez le downgrade vers HTTP/1.1
WAF en mode strict : Rejeter toute requête avec CL et TE simultanés

3. Validation applicative

from flask import request, abort

@app.before_request
def prevent_smuggling():
    if 'Transfer-Encoding' in request.headers and 'Content-Length' in request.headers:
        abort(400, "Ambiguous request")

4. Tests réguliers

Intégrez des tests de smuggling dans votre pipeline CI/CD.

Checklist de sécurité

Vérification	Action
Requêtes avec CL+TE rejetées	Configurer le serveur
Headers TE obfusqués rejetés	Validation stricte
HTTP/2 sans downgrade	Architecture moderne
WAF configuré en mode strict	Configuration sécurité
Tests de smuggling automatisés	Pipeline CI/CD
Monitoring des requêtes malformées	Alerting

Conclusion

Le HTTP Request Smuggling représente une classe d'attaques particulièrement dangereuse car elle opère à un niveau que la plupart des outils de sécurité ignorent. Dans un monde où les architectures distribuées deviennent la norme, comprendre et tester cette vulnérabilité est essentiel.

Chez RedSentinel, nos audits de sécurité incluent systématiquement des tests de Request Smuggling sur l'ensemble de votre chaîne de traitement HTTP. Nous identifions les désynchronisations entre vos différentes couches et vous aidons à implémenter des corrections durables.

Ressources complémentaires

HTTP Desync Attacks - PortSwigger Research
HTTP/2: The Sequel is Always Worse - James Kettle
RFC 7230 - HTTP/1.1 Message Syntax