Le HTTP request smuggling est une vulnérabilité qui résulte d’incohérences dans l’analyse des requêtes HTTP entre plusieurs dispositifs. Ces vulnérabilités se produisent lorsqu’un dispositif front-end (par exemple, Content Delivery Network, Load Balancer, WAF), et un dispositif back-end (par exemple, serveur web) interprètent différemment la fin de la requête HTTP, en raison de la présence de différents en-têtes HTTP (c’est-à-dire, Transfer-Encoding, Content-Length). Cela peut entraîner un contournement des contrôles de sécurité, la possibilité de lancer des attaques (par exemple, XSS) contre d’autres utilisateurs, un empoisonnement du cache, un Déni de service, ou d’autres attaques selon l’application. Le HTTP requête smuggling peut également être appelé CWE-444, HTTP réponse smuggling, ou HTTP smuggling.

Il existe de nombreux types de vulnérabilités de contrebande de requêtes HTTP, selon la version du protocole, l’ordre des en-têtes, et l’environnement. Nous allons détailler chacun d’entre eux dans les sections suivantes.

Ce que nous allons aborder :

1. Quels sont les différents types de contrebande de requêtes HTTP ?

2. Contrebande de requêtes HTTP/1.1

3. Contrebande de requêtes HTTP/2

4. Impacts de la contrebande de requêtes HTTP

5. Comment Fastly empêche la contrebande de requêtes HTTP

6. Comment prévenir le détournement de requêtes HTTP

7. Résumé

Quels sont les différents types de contrebande de requêtes HTTP ?

Contrebande de requêtes HTTP/1.1

Les requêtes HTTP utilisant la version 1.1 peuvent indiquer la fin de leur requête à l’aide des en-tête Content-Length ou Transfer-Encoding. Lorsque les dispositifs front-end et back-end n’utilisent pas le même de ces deux en-têtes pour déterminer la fin de la requête, ils peuvent analyser la fin de la requête différemment, ce qui entraîne une vulnérabilité de type HTTP request smuggling. 

Pour les exemples suivants, nous démontrerons l’impact du smuggling de requêtes par le biais d’un contournement de l’autorisation. Dans ce scénario, le serveur front-end empêche l’accès à la page /admin, mais il n’y a aucune validation supplémentaire sur le back-end. Étant donné que le back-end n’effectue pas non plus de validation, le request smuggling peut nous permettre de contourner cette vérification de l’autorisation. 

Vulnérabilités CL.TE

Une vulnérabilité CL.TE désigne une attaque de contrebande de requêtes HTTP dans laquelle le front-end utilise l’en-tête Content-Length, mais le back-end utilise l’en-tête Transfer-Encoding. 

Dans l’exemple suivant, le front-end utilise l’en-tête Content-Length, lit l’intégralité du contenu comme une seule requête et la transmet au back-end. Cependant, le serveur back-end utilise l’en-tête Transfer-Encoding et interprète la fin de la requête à 0\r\n\r\n (deux nouvelles lignes après un bloc 0 que Transfer-Encoding utilise pour indiquer la fin d’une requête). Le back-end interprète donc cela comme deux requêtes.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

0

GET /admin HTTP/1.1
Example: x

À présent, lorsque davantage de données transitent par la connexion (par exemple, nous envoyons à nouveau la requête), le serveur back-end les ajoute au début de cette deuxième requête smuggled, car elle n’a pas été terminée. Cela amène le serveur back-end à considérer ce qui suit comme la deuxième requête :

GET /admin HTTP/1.1
Example: xPOST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

Le serveur back-end interprète cela comme une requête GET pour /admin, qui a été introduite clandestinement au-delà du serveur front-end, qui n’a interprété que les deux requêtes POST. Cette vulnérabilité de contrebande de requêtes permet désormais au hacker de contourner la vérification de l’autorisation par le front-end. 

Vulnérabilités TE.CL

Une vulnérabilité TE.CL désigne une attaque de contrebande de requêtes HTTP dans laquelle le front-end utilise l’en-tête Transfer-Encoding, mais le back-end utilise l’en-tête Content-Length. 

Dans l’exemple suivant, le front-end utilise l’en-tête Transfer-Encoding, lit l’intégralité du contenu comme une seule requête, et la transmet au back-end. Le back-end utilise l’en-tête Content-Length, et interprète donc cela comme deux requêtes.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0
GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 150

x
0

Alors que le serveur front-end a terminé sa requête, le serveur back-end attend toujours du contenu supplémentaire provenant du long Content-Length dans la requête de contrebande. Lorsque davantage de données transitent par la connexion (par exemple, nous renvoyons la requête), le serveur back-end les ajoute au début de cette deuxième requête de contrebande, car elle n’a pas été terminée. Cela amène le serveur back-end à considérer ce qui suit comme la deuxième requête :

GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 141

x
0

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0

Le serveur back-end interprète cela comme une requête GET pour /admin, qui a été introduite clandestinement au-delà du serveur front-end, qui n’a interprété que les deux requêtes POST. Cette vulnérabilité de contrebande de requêtes permet désormais au hacker de contourner la vérification de l’autorisation par le front-end. 

Obfuscation et smuggling des en-têtes

Il est possible que certains dispositifs ignorent les en-tête Transfer-Encoding mal formés, tandis que d’autres peuvent les traiter même en présence de légères erreurs (par ex., espaces supplémentaires, en-tête en double, etc.) Si c’est le cas, cela peut faciliter l’exploitation de l’une des vulnérabilités CL.TE ou TE.CL susmentionnées, car un dispositif traite l’en-tête mal formé, tandis que l’autre l’ignore.

Contrebande de requêtes HTTP/2

Bien que le détournement classique de requête HTTP doive être atténué via HTTP/2, il existe encore des moyens de détourner des requêtes à l’aide de HTTP/2, en particulier lorsque les serveurs back-end ne prennent en charge que HTTP/1.1. 

HTTP/2 est un protocole binaire envoyé dans des trames, chaque trame étant précédée de la longueur de la trame. Un en-tête Content-Length n’est pas requis, et l’en-tête Transfer-Encoding n’est pas pris en charge. Nous afficherons ces requêtes comme elles le seraient en HTTP/1.1 pour plus de lisibilité, mais gardez à l’esprit que les données réellement envoyées se présentent différemment en HTTP/2.

Rétrogradation HTTP/2

Lorsque les dispositifs back-end (par ex., les serveurs web) ne prennent en charge que HTTP/1.1, mais que les dispositifs front-end (par ex., les Content Delivery Network) et les clients utilisent HTTP/2, les dispositifs front-end réécrivent la requête HTTP/2 qu’ils reçoivent en HTTP/1.1 avant de l’envoyer au back-end. On parle alors de rétrogradation HTTP/2, et c’est en exploitant des erreurs dans cette réécriture que surviennent les vulnérabilités de requête smuggling.

Vulnérabilités H2.CL

HTTP/2 ne nécessite pas d’en-tête Content-Length, et si un en-tête est fourni, il est censé être validé par rapport à la longueur calculée du message. Lorsqu’un dispositif réécrit une requête en HTTP/1.1, il doit utiliser la longueur calculée pour l’en-tête Content-Length traduit. Cependant, certains dispositifs front-end peuvent, à la place, utiliser l’en-tête Content-Length fourni lors de l’exécution de la rétrogradation. Si cela se produit, le back-end utilisera un Content-Length différent de celui du front-end, ce qui entraînera une vulnérabilité de type smuggling.

Vulnérabilités H2.TE

L’en-tête Transfer-Encoding n’est pas utilisé dans HTTP/2, et il est recommandé soit de supprimer l’en-tête, soit de rejeter les requêtes HTTP/2 qui comportent un en-tête Transfer-Encoding. Si le dispositif front-end ne le fait pas, puis réécrit la requête avec l’en-tête Transfer-Encoding, il est possible de faire passer l’en-tête jusqu’au back-end. L’exploitation de cette faille nécessiterait que le back-end prenne en charge Transfer-Encoding plutôt que Content-Length, mais ce serait alors identique à une exploitation CL.TE en HTTP/1.1.

Impacts de la contrebande de requêtes HTTP

Le HTTP request smuggling a des impacts très variés selon l’application, car il interfère avec la frontière entre plusieurs requêtes. Nos exemples précédents ont couvert un contournement d’autorisation, et nous en aborderons un autre qui affecte d’autres utilisateurs, mais il en existe bien d’autres, décrits plus en détail par les équipes de Portswigger, qui mènent des recherches approfondies sur le HTTP request smuggling.

Exemple concret : exploiter avec une XSS réfléchie

Dans cet exemple, supposons que le serveur front-end détermine la longueur de la requête en fonction de Content-Length, et que le serveur back-end la détermine en fonction de Transfer-Encoding. Supposons également que le serveur web soit vulnérable au Cross-Site Scripting (XSS) réfléchi lorsqu’une charge utile se trouve dans l’en-tête Referrer. Normalement, une XSS réfléchie dans l’en-tête Referer est difficile à exploiter, car elle ne peut pas être exploitée avec un simple lien comme elle pourrait l’être dans un paramètre de requête. Dans ce scénario, un hacker envoie la requête suivante :

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 111
Transfer-Encoding: chunked

1
q=smuggling
0

GET /vulnerable-page HTTP/1.1
Referrer: ”><script>print(1)</script>
Example: x

Le front-end utilise l’en-tête Content-Length et l’interprète comme une seule requête, qu’il transmet au back-end. Le back-end utilise Transfer-Encoding et l’interprète comme deux requêtes, la première étant mise en évidence en rouge, et la seconde en bleu. La seconde requête est incomplète, le back-end attend donc davantage de données. Lorsqu’un autre utilisateur envoie ensuite une requête à /home, la réponse du serveur web provient de la requête dissimulée du hacker, ce qui entraîne la distribution de la charge utile XSS réfléchie dans la réponse adressée à l’utilisateur victime. Dans ce scénario, le back-end interprète la requête de l’utilisateur victime comme suit :

GET /vulnerable-page HTTP/1.1
Referrer: "><script>print(1)</script>
Example: xGET /home HTTP/1.1
Host: example.com
...rest of victim user's request...

L’utilisateur victime a envoyé une requête à /home, mais a reçu à la place la réponse à /vulnerable-page avec la charge utile XSS réfléchie. En pratique, en raison du volume de requêtes, de la réutilisation des connexions, etc., il faudra de nombreuses requêtes pour qu’un utilisateur reçoive la réponse XSS mise en file d’attente, mais cela peut rapidement affecter un large éventail d’utilisateurs en envoyant rapidement des requêtes de smuggling pour empoisonner les connexions avec des charges utiles XSS. 

Comment Fastly empêche la contrebande de requêtes HTTP

Fastly empêche la contrebande de requêtes HTTP en analysant les requêtes de manière stricte et conforme. Cela se fait de plusieurs façons :

• Analyse stricte des protocoles : Fastly analyse toutes les requêtes HTTP avec un degré élevé de rigueur, conformément aux normes. Cela supprime l’ambiguïté que les hackers utilisent pour exploiter les vulnérabilités de contrebande de requêtes.

• Normalisation des requêtes : Fastly rejette ou normalise les requêtes ambiguës en périphérie. Par exemple, une requête contenant à la fois un en-tête Content-Length et un en-tête Transfer-Encoding sera traitée de manière à l’empêcher d’atteindre votre origine dans un état exploitable.

• Rejet des requêtes non valides : Fastly refuse les requêtes GET et HEAD qui contiennent un corps. Lorsque cela se produit, Fastly envoie une réponse 400 Bad Request, empêchant la requête d’atteindre l’origine. S’il est configuré pour l’autoriser, les requêtes pass transmettront les corps des requêtes GET et HEAD à l’origine. Si vous avez un besoin spécifique d’activer les corps pour ces requêtes, vous devez contacter notre équipe d’assistance.

Comment prévenir le détournement de requêtes HTTP

• Normaliser les requêtes ambiguës

  • Les serveurs front-end qui reçoivent à la fois des en-tête CL et TE doivent normaliser les requêtes selon un seul mécanisme pour déterminer la longueur d’une requête, et supprimer les en-tête superflus afin d’empêcher les origines de recevoir des requêtes ambiguës.

• Rejeter les requêtes mal formées (HTTP/2 et HTTP/1.1)

  • Le rejet des requêtes comportant des en-tête mal formés, des en-tête en double, etc. contribuera à prévenir les vulnérabilités qui peuvent dépendre de l’acceptation, par les serveur, d’en-tête mal formés. Cela empêchera également les vulnérabilités CL et TE de rétrogradation HTTP/2 qui reposent sur la transmission au back-end d’en-têtes supplémentaires inutiles.

• Valider lors du retour à HTTP/1.1

  • Les serveurs front-end qui rétrogradent vers HTTP/1.1 doivent vérifier que les requêtes réécrites ne sont ni malformées, ni ambiguës. Par exemple, après réécriture, un serveur front-end doit effectuer la même normalisation que celle qu’il effectuerait sur une requête HTTP/1.1 classique.

• Envisagez de désactiver la réutilisation des connexions back-end

  • De nombreuses attaque de type request smuggling exploitent la réutilisation des connexions entre le front-end et le back-end. L’exemple de XSS fait cela, où plusieurs utilisateur envoyant des requête partagent une connexion du front-end au back-end, et le smuggling entraîne un mélange des réponse. La désactivation de la réutilisation des connexions empêche ce type d’attaque, mais n’empêche pas toutes les attaques par smuggling, et n’empêche pas les techniques avancées telles que le tunneling de requête. Cela peut également avoir un impact sur les performances, et ne constitue qu’une atténuation "partial".

• Utilisez HTTP/2 de bout en bout si possible

  • HTTP/2 est intrinsèquement protégé contre la contrebande de requêtes lorsque la rétrogradation est désactivée. Lorsque cela est possible, son utilisation constitue la meilleure atténuation.

Résumé

Le smuggling de requêtes HTTP est une vulnérabilité qui découle d’incohérences dans l’analyse des requêtes HTTP entre plusieurs dispositifs, et peut avoir des conséquences dévastatrices, telles qu’un contournement de l’autorisation, la capacité de lancer des attaques (par ex., XSS) contre d’autres utilisateurs, l’empoisonnement du cache, le Déni de service, et plus encore. Bien que HTTP/2  et la désactivation du downgrading empêchent le smuggling de requêtes, les organisations devraient également envisager de rejeter les requêtes malformées, de normaliser les requêtes ambiguës, et de valider le schéma HTTP afin de limiter davantage la surface d’attaque si le downgrading doit être pris en charge.

Pour en savoir plus sur les offres de sécurité de Fastly qui peuvent vous aider à vous protéger contre les attaques de type HTTP request smuggling, et plus encore.