Spesiale HTTP-opskrifte

Reading time: 12 minutes

Woordlyste & Gereedskap

• https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers
• https://github.com/rfc-st/humble

Opskrifte om ligging te verander

Herskryf IP-bron:

• X-Originating-IP: 127.0.0.1
• X-Forwarded-For: 127.0.0.1
• X-Forwarded: 127.0.0.1
• Forwarded-For: 127.0.0.1
• X-Forwarded-Host: 127.0.0.1
• X-Remote-IP: 127.0.0.1
• X-Remote-Addr: 127.0.0.1
• X-ProxyUser-Ip: 127.0.0.1
• X-Original-URL: 127.0.0.1
• Client-IP: 127.0.0.1
• X-Client-IP: 127.0.0.1
• X-Host: 127.0.0.1
• True-Client-IP: 127.0.0.1
• Cluster-Client-IP: 127.0.0.1
• Via: 1.0 fred, 1.1 127.0.0.1
• Connection: close, X-Forwarded-For (Kontroleer hop-by-hop-opskrifte)

Herskryf ligging:

• X-Original-URL: /admin/console
• X-Rewrite-URL: /admin/console

Hop-by-Hop-opskrifte

'n Hop-by-hop-opskrif is 'n opskrif wat ontwerp is om verwerk en verbruik te word deur die proxy wat tans die versoek hanteer, in teenstelling met 'n end-to-end-opskrif.

• Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

• Content-Length: 30
• Transfer-Encoding: chunked

HTTP Request Smuggling / HTTP Desync Attack

Die Expect-opskrif

Dit is moontlik vir die kliënt om die opskrif Expect: 100-continue te stuur, waarna die bediener met HTTP/1.1 100 Continue kan antwoord om die kliënt toe te laat om voort te gaan om die liggaam van die versoek te stuur. Sommige proxies hou egter nie regtig van hierdie opskrif nie.

Interessante gevolge van Expect: 100-continue:

• Om 'n HEAD-versoek met 'n liggaam te stuur het veroorsaak dat die bediener nie in ag geneem het dat HEAD-versoeke geen liggaam het nie, en die verbinding oopgehou het totdat dit verval het.
• Ander bedieners het vreemde data teruggestuur: lukrake data wat vanaf die sok gelees is in die respons, geheime sleutels, of dit het selfs toegelaat om te verhoed dat die front-end opskrifwaardes verwyder.
• Dit het ook 'n 0.CL desync veroorsaak omdat die backend met 'n 400-respons in plaas van 'n 100-respons geantwoord het, maar die proxy front-end was gereed om die liggaam van die aanvanklike versoek te stuur; dit stuur dit en die backend neem dit as 'n nuwe versoek.
• Om 'n variasie soos Expect: y 100-continue te stuur het ook die 0.CL desync veroorsaak.
• 'n Gelyksoortige fout waar die backend met 'n 404 geantwoord het, het 'n CL.0 desync gegenereer omdat die kwaadwillige versoek 'n Content-Length aandui. Die backend stuur dus die kwaadwillige versoek plus die Content-Length bytes van die volgende versoek (van 'n slagoffer). Dit desinkroniseer die ry omdat die backend die 404-respons vir die kwaadwillige versoek stuur plus die respons van die slagoffer se versoek, maar die front-end dink dat slegs 1 versoek gestuur is; dus word die tweede respons aan 'n tweede slagoffer versoek gestuur en die respons van daardie een aan die volgende, ensovoorts...

Vir meer inligting oor HTTP Request Smuggling, kyk:

HTTP Request Smuggling / HTTP Desync Attack

Kas-opskrifte

Bediener-kas-opskrifte:

• X-Cache in die respons kan die waarde miss hê wanneer die versoek nie in die kas was nie en die waarde hit wanneer dit in die kas is
• Gelyke gedrag in die opskrif Cf-Cache-Status
• Cache-Control dui aan of 'n bron gekas word en vir hoe lank: Cache-Control: public, max-age=1800
• Vary word dikwels in die respons gebruik om bykomende opskrifte aan te dui wat as deel van die kas-sleutel beskou word, selfs al is hulle gewoonlik nie gekey nie.
• Age gee die tyd in sekondes aan wat die objek in die proxy-kas is.
• Server-Timing: cdn-cache; desc=HIT dui ook aan dat 'n bron gekas is

Cache Poisoning and Cache Deception

Plaaslike kas-opskrifte:

• Clear-Site-Data: Opskrif om aan te dui watter kas verwyder moet word: Clear-Site-Data: "cache", "cookies"
• Expires: Bevat die datum/tyd wanneer die respons behoort te verval: Expires: Wed, 21 Oct 2015 07:28:00 GMT
• Pragma: no-cache dieselfde as Cache-Control: no-cache
• Warning: Die Warning algemene HTTP-opskrif bevat inligting oor moontlike probleme met die status van die boodskap. Meer as een Warning-opskrif kan in 'n respons verskyn. Warning: 110 anderson/1.3.37 "Response is stale"

Voorwaardelike versoeke

• Versoeke wat hierdie opskrifte gebruik: If-Modified-Since en If-Unmodified-Since word slegs met data beantwoord as die respons-opskrif Last-Modified 'n ander tyd bevat.
• Voorwaardelike versoeke wat If-Match en If-None-Match gebruik maak 'n ETag-waarde sodat die webbediener die inhoud van die respons sal stuur as die data (ETag) verander het. Die Etag word uit die HTTP-respons gehaal.
• Die Etag-waarde word gewoonlik bereken op grond van die inhoud van die respons. Byvoorbeeld, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" dui aan dat die Etag die Sha1 van 37 bytes is.

Range-versoeke

• Accept-Ranges: Dui aan of die bediener range-versoeke ondersteun, en in watter eenheid die reeks uitgedruk kan word. Accept-Ranges: <range-unit>
• Range: Dui die deel van 'n dokument aan wat die bediener moet teruggee. Byvoorbeeld, Range:80-100 sal die bytes 80 tot 100 van die oorspronklike respons teruggee met 'n statuskode van 206 Partial Content. Onthou ook om die Accept-Encoding-opskrif uit die versoek te verwyder.
• Dit kan nuttig wees om 'n respons met ewekansige gereflekteerde javascript-kode te kry wat andersins ontsnap sou word. Om dit te misbruik sal jy egter hierdie opskrifte in die versoek moet injekteer.
• If-Range: Skep 'n voorwaardelike range-versoek wat slegs uitgevoer word as die gegewe etag of datum met die afgeleë hulpbron ooreenstem. Word gebruik om te voorkom dat twee reekse van 'n onverenigbare weergawe van die hulpbron afgelaai word.
• Content-Range: Dui aan waar 'n gedeeltelike boodskap in 'n volledige liggaam behoort te wees.

Inligting oor boodskapliggaam

• Content-Length: Die grootte van die hulpbron, in desimale getal van bytes.
• Content-Type: Dui die media-tipe van die hulpbron aan
• Content-Encoding: Word gebruik om die kompressie-algoritme te spesifiseer.
• Content-Language: Beskryf die menslike taal(-tale) waarna dit bedoel is, sodat 'n gebruiker kan onderskei volgens hul eie voorkeurtaal.
• Content-Location: Dui 'n alternatiewe ligging vir die teruggegewe data aan.

Vanuit 'n pentest-perspektief is hierdie inligting gewoonlik nutteloos, maar as die bron beskerm is deur 'n 401 of 403 en jy kan 'n manier vind om hierdie info te kry, kan dit interessant wees.
Byvoorbeeld, 'n kombinasie van Range en Etag in 'n HEAD-versoek kan die inhoud van die bladsy via HEAD-versoeke leak:

• A request with the header Range: bytes=20-20 and with a response containing ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" is leaking that the SHA1 of the byte 20 is ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Bediener-inligting

• Server: Apache/2.4.1 (Unix)
• X-Powered-By: PHP/5.3.3

Kontroles

• Allow: Hierdie opskrif word gebruik om die HTTP-metodes te kommunikeer wat 'n hulpbron kan hanteer. Byvoorbeeld, dit kan gespesifiseer wees as Allow: GET, POST, HEAD, wat aandui dat die hulpbron hierdie metodes ondersteun.
• Expect: Word deur die kliënt gebruik om verwagtinge oor te dra wat die bediener moet vervul sodat die versoek suksesvol verwerk kan word. 'n Algemene gebruik is die Expect: 100-continue-opskrif, wat aandui dat die kliënt 'n groot datalading wil stuur en op 'n 100 (Continue)-respons wag voordat dit voortgaan. Hierdie meganisme help om netwerkverbruik te optimaliseer deur op bedienerbevestiging te wag.

Aflaaie

• Die Content-Disposition opskrif in HTTP-responses bepaal of 'n lêer inline (within the webpage) vertoon moet word of as 'n attachment (downloaded) behandel moet word. Byvoorbeeld:

Content-Disposition: attachment; filename="filename.jpg"

Dit beteken dat die lêer met die naam "filename.jpg" bedoel is om afgelaai en gestoor te word.

Security Headers

Content Security Policy (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Deur Trusted Types via CSP af te dwing, kan toepassings teen DOM XSS-aanvalle beskerm word. Trusted Types verseker dat slegs spesifiek vervaardigde objekte, wat voldoen aan gevestigde sekuriteitsbeleid, in gevaarlike web API-aanroepe gebruik kan word, en sodoende JavaScript-kode standaard beveilig.

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
});
}

// Assignment of raw strings is blocked, ensuring safety.
el.innerHTML = "some string" // Throws an exception.
const escaped = policy.createHTML("<img src=x onerror=alert(1)>")
el.innerHTML = escaped // Results in safe assignment.

X-Content-Type-Options

Hierdie header verhoed MIME-tipe-snuffeling, 'n praktyk wat tot XSS-kwesbaarhede kan lei. Dit verseker dat blaaiers die deur die bediener gespesifiseerde MIME-tipes respekteer.

X-Content-Type-Options: nosniff

X-Frame-Options

Om clickjacking te bekamp, beperk hierdie header hoe dokumente in <frame>, <iframe>, <embed> of <object>-tags ingebed kan word, en beveel aan dat alle dokumente hul inbeddingstoestemmings uitdruklik moet spesifiseer.

X-Frame-Options: DENY

Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)

CORP is noodsaaklik om te spesifiseer watter hulpbronne deur webwerwe gelaai kan word en help om cross-site leaks te beperk. CORS, aan die ander kant, maak 'n meer buigsame cross-origin resource sharing-meganisme moontlik en versoepel die same-origin policy onder sekere toestande.

Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Cross-Origin Embedder-beleid (COEP) en Cross-Origin Opener-beleid (COOP)

COEP en COOP is noodsaaklik om cross-origin isolasie moontlik te maak, wat die risiko van Spectre-agtige aanvalle aansienlik verminder. Hulle beheer onderskeidelik die laai van cross-origin hulpbronne en die interaksie met cross-origin vensters.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups

HTTP Strict Transport Security (HSTS)

Laastens, HSTS is 'n sekuriteitsfunksie wat blaaiers dwing om slegs oor veilige HTTPS-verbindinge met bedieners te kommunikeer, en sodoende privaatheid en sekuriteit te verbeter.

Strict-Transport-Security: max-age=3153600

Header Name Casing Bypass

HTTP/1.1 definieer header-veldname as case-insensitive (RFC 9110 §5.1). Nietemin is dit baie algemeen om custom middleware, security filters, of business logic te vind wat die letterlike headernaam vergelyk wat ontvang is sonder om eers die kastering te normaliseer (bv. header.equals("CamelExecCommandExecutable")). As daardie kontroles case-sensitively uitgevoer word, kan 'n aanvaller dit eenvoudig omseil deur dieselfde header met 'n ander kapitalisering te stuur.

Tipiese situasies waar hierdie fout verskyn:

• Aangepaste allow/deny-lyste wat probeer om “gevaarlike” interne headers te blokkeer voordat die aanvraag 'n sensitiewe komponent bereik.
• In-huis implementasies van reverse-proxy pseudo-headers (e.g. X-Forwarded-For sanitisation).
• Frameworks wat management / debug endpoints blootstel en op headername staatmaak vir autentisering of opdragkeuse.

Abusing the bypass

1. Identifiseer 'n header wat aan die bedienerkant gefilter of gevalideer word (byvoorbeeld deur bronkode, dokumentasie of foutboodskappe te lees).
2. Stuur die dieselfde header met 'n ander kastering (gemengde letters of hoofletters). Omdat HTTP-stakke gewoonlik headers eers kanoniseer na gebruikerskode gedraai het, kan die kwesbare kontrole oorgeslaan word.
3. As die downstream-komponent headers op 'n case-insensitive wyse hanteer (meeste doen dit), sal dit die aanvaller-beheerde waarde aanvaar.

Example: Apache Camel exec RCE (CVE-2025-27636)

In kwesbare weergawes van Apache Camel probeer die Command Center routes onbetroubare versoeke blokkeer deur die headers CamelExecCommandExecutable en CamelExecCommandArgs te verwyder. Die vergelyking is gedoen met equals() so slegs die presiese lowercase name is verwyder.

# Bypass the filter by using mixed-case header names and execute `ls /` on the host
curl "http://<IP>/command-center" \
-H "CAmelExecCommandExecutable: ls" \
-H "CAmelExecCommandArgs: /"

Die headers bereik die exec component ongefilter, wat lei tot remote command execution met die voorregte van die Camel-proses.

Opsporing & Mitigering

• Normaliseer alle header names na 'n enkele case (gewoonlik lowercase) voor die uitvoering van allow/deny-vergelykings.
• Verwerp verdagte duplikate: as beide Header: en HeAdEr: teenwoordig is, beskou dit as 'n anomalie.
• Gebruik 'n positiewe allow-list wat na canonicalisation afgedwing word.
• Beskerm management endpoints met authentication en netwerk-segmentering.

Verwysings

• CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• https://web.dev/security-headers/
• https://web.dev/articles/security-headers