🤝HTTP Smuggling

Basic

Les attaques de contrebande de requêtes impliquent de placer à la fois l'en-tête Content-Length et l'en-tête Transfer-Encoding dans une seule requête HTTP et de les manipuler de sorte que les serveurs front-end et back-end traitent la requête différemment. La manière exacte dont cela se fait dépend du comportement des deux serveurs :

• CL.TE : le serveur front-end utilise l'en-tête Content-Length et le serveur back-end utilise l'en-têteTransfer-Encoding.

• TE.CL : le serveur front-end utilise l'en-tête Transfer-Encodinget le serveur back-end utilise l'en-tête Content-Length.

• TE.TE : les serveurs front-end et back-end prennent tous deux en charge l'en-tête Transfer-Encoding, mais l'un des serveurs peut être incité à ne pas le traiter en masquant l'en-tête d'une manière ou d'une autre.

CL.TE

Dans ce cas, le serveur front-end utilise l'en-tête Content-Length et le back-end l'en-tête Transfer-Encoding.

Il est donc possible d'exploiter la cible comme ceci:

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

0

SMUGGLED

Le serveur front-end traite l'en-tête Content-Length et détermine que le corps de la requête a une longueur de 13 octets, jusqu'à la fin de SMUGGLED. Cette demande est transmise au serveur principal.

Le serveur principal traite l'en-tête Transfer-Encoding et traite donc le corps du message comme utilisant un codage fragmenté. Il traite le premier bloc, qui est déclaré être de longueur nulle, et est donc traité comme mettant fin à la demande. Les octets suivants, SMUGGLED, ne sont pas traités et le serveur principal les traitera comme étant le début de la requête suivante dans la séquence.

TE.CL

Dans ce cas, le serveur front-end utilise l'en-tête Transfer-Encoding et le back-end l'en-tête Content-Length.

Il est donc possible d'exploiter la cible comme ceci:

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

8
SMUGGLED
0

Pour envoyer cette requête à l'aide de Burp Repeater, vous devrez d'abord vous rendre dans le menu Repeater et vous assurer que l'option "Update Content-Length" est décochée.

Vous devez inclure la séquence de fin \r\n\raprès le final 0.

Ici, le serveur front-end traite l'en-tête Transfer-Encoding et traite ainsi le corps du message comme utilisant un codage fragmenté. Il traite le premier bloc, qui est censé avoir une longueur de 8 octets, jusqu'au début de la ligne suivant SMUGGLED. Il traite le deuxième bloc, qui est déclaré être de longueur nulle, et est donc traité comme mettant fin à la demande. Cette demande est transmise au serveur back-end.

Le serveur back-end traite l'en-tête Content-Length et détermine que le corps de la requête a une longueur de 3 octets, jusqu'au début de la ligne suivant 8. Les octets suivants, commençant par SMUGGLED, ne sont pas traités et le serveur principal les traitera comme étant le début de la requête suivante dans la séquence

TE.TE

Pour ce dernier cas, pour découvrir une vulnérabilité TE.TE, il est nécessaire de trouver une variation de l' en-tête Transfer-Encoding telle qu'un seul des serveurs front-end ou back-end la traite, tandis que l'autre serveur l'ignore.

Selon que c'est le serveur front-end ou le serveur back-end qui peut être amené à ne pas traiter l'en-tête Transfer-Encodingobfusqué, la suite de l'attaque prendra la même forme que pour les vulnérabilités CL.TE ou TE.CL déjà décrites.

Il existe des façons potentiellement infinies d'obfusquer l'en-tête Transfer-Encoding.

Quelques exemples ci-dessous:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked