Spesiale HTTP-headers

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

Wordlists & Gereedskap

Hoofde 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 (Check hop-by-hop headers)

Herskryf ligging:

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

Hop-by-Hop hoofde

’n hop-by-hop header is ’n header wat ontwerp is om verwerk en gebruik te word deur die proxy wat tans die versoek hanteer, in teenstelling met ’n end-to-end header.

  • 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-header

Dit is moontlik dat die kliënt die header Expect: 100-continue stuur en dat 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 header nie.

Interessante resultate van Expect: 100-continue:

  • Die stuur van ’n HEAD-versoek met ’n body — die bediener het nie geag dat HEAD-versoeke geen body het nie en hou die verbinding oop totdat dit verstryk.
  • Ander bedieners het vreemde data teruggestuur: ewekansige data wat vanaf die sok gelees is in die response, geheime sleutels, of dit het selfs toegelaat om te voorkom dat die front-end headerwaardes verwyder.
  • Dit het ook ’n 0.CL desync veroorsaak omdat die backend met ’n 400-antwoord in plaas van ’n 100-antwoord geantwoord het, maar die proxy front-end was gereed om die liggaam van die aanvanklike versoek te stuur, so dit stuur dit en die backend beskou dit as ’n nuwe versoek.
  • Die stuur van ’n Expect: y 100-continue variasie het ook die 0.CL desync veroorsaak.
  • ’n Soortgelyke fout waar die backend met ’n 404 geantwoord het, het ’n CL.0 desync gegenereer omdat die kwaadwillige versoek ’n Content-Length aandui, sodat die backend die kwaadwillige versoek stuur plus die Content-Length bytes van die volgende versoek (van ’n slagoffer). Dit desinkroniseer die tou omdat die backend die 404-antwoord stuur vir die kwaadwillige versoek plus die antwoord van die slagoffer-versoeke, maar die front-end het gedink slegs 1 versoek is gestuur, so die tweede antwoord word na ’n tweede slagoffer-versoek gestuur en die antwoord daarvan word na die volgende een gestuur…

Vir meer inligting oor HTTP Request Smuggling, sien:

HTTP Request Smuggling / HTTP Desync Attack

Cache-hoofde

Server Cache-hoofde:

  • 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
  • Vergelykbare gedrag in die header Cf-Cache-Status
  • Cache-Control dui aan of ’n bron gekas word en wanneer dit weer ververs sal word: Cache-Control: public, max-age=1800
  • Vary word dikwels in die response gebruik om addisionele header(s) aan te dui wat as deel van die cache-sleutel beskou word, selfs al is hulle gewoonlik nie gesleutel nie.
  • Age definieer die tyd in sekondes wat die objek al in die proxy-kas is.
  • Server-Timing: cdn-cache; desc=HIT dui ook aan dat ’n bron gekas is

Cache Poisoning and Cache Deception

Lokale cache-hoofde:

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

Voorwaardelike versoeke

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

Range-versoeke

  • Accept-Ranges: Dui aan of die bediener range-versoeke ondersteun, en indien wel in watter eenheid die range uitgedruk kan word. Accept-Ranges: <range-unit>
  • Range: Dui die deel van ’n dokument aan wat die bediener behoort terug te stuur. Byvoorbeeld, Range:80-100 sal die bytes 80 tot 100 van die oorspronklike respons terugstuur met ’n statuskode van 206 Partial Content. Onthou ook om die Accept-Encoding header uit die versoek te verwyder.
  • Dit kan nuttig wees om ’n response met ewekansige gereflekteerde JavaScript-kode te kry wat andersins ontsnap sou word. Maar om dit te misbruik moet jy hierdie headers in die versoek injekteer.
  • If-Range: Skep ’n voorwaardelike range-versoek wat slegs vervul word as die gegewe etag of datum ooreenstem met die afstandbron. Word gebruik om te verhoed dat twee ranges van ongematcheerde weergawes van die bron afgelaai word.
  • Content-Range: Dui aan waar in ’n volledige liggaamsboodskap ’n gedeeltelike boodskap behoort te pas.

Inligting oor boodskapliggaam

  • Content-Length: Die grootte van die bron, in desimale aantal bytes.
  • Content-Type: Dui die media-tipe van die bron aan
  • Content-Encoding: Word gebruik om die kompressie-algoritme te spesifiseer.
  • Content-Language: Beskryf die menslike taal(e) vir die beoogde gehoor, sodat dit ’n gebruiker toelaat om te onderskei volgens die gebruiker se eie voorkeurtaal.
  • Content-Location: Dui ’n alternatiewe ligging vir die teruggestuurde data aan.

Vanuit ’n pentest-perspektief is hierdie inligting gewoonlik “nutloos”, maar as die bron deur ’n 401 of 403 beskerm word 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:

  • ’n versoek met die header Range: bytes=20-20 en met ’n response wat ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" bevat, is leaking dat die SHA1 van byte 20 ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y is

Bediener-inligting

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

Kontroles

  • Allow: Hierdie header word gebruik om die HTTP-metodes wat ’n bron kan hanteer te kommunikeer. Byvoorbeeld, dit kan gespesifiseer word as Allow: GET, POST, HEAD, wat aandui dat die bron hierdie metodes ondersteun.
  • Expect: Word deur die kliënt gebruik om verwagtinge oor te dra wat die bediener moet nakom vir die versoek om suksesvol verwerk te word. ’n Algemene geval is die header Expect: 100-continue, wat aandui dat die kliënt ’n groot datalading wil stuur. Die kliënt soek ’n 100 (Continue) antwoord voordat dit voortgaan met die oordrag. Hierdie meganisme help om netwerkverkeer te optimaliseer deur op bedienerbevestiging te wag.

Aflaaie

  • Die Content-Disposition header in HTTP-responses bepaal of ’n lêer inline (binne die webblad) vertoon moet word of as ’n attachment behandel moet word (gedownload). 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.

Sekuriteitskoppe

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 opgestelde objekte, wat aan gevestigde veiligheidsbeleid voldoen, in gevaarlike web API-oproepe gebruik kan word, en sodoende JavaScript-kode per verstek 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 koptekst voorkom MIME type sniffing, ’n praktyk wat tot XSS-kwesbaarhede kan lei. Dit verseker dat blaaiers die MIME-tipes soos deur die bediener gespesifiseer, 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 ingebedingsmagte uitdruklik spesifiseer.

X-Frame-Options: DENY

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

CORP is noodsaaklik om te spesifiseer watter hulpbronne deur webwerwe gelaai kan word, en om cross-site leaks te beperk. CORS laat, aan die ander kant, ’n meer buigsame meganisme toe vir cross-origin resource sharing, en verslap die same-origin policy onder sekere omstandighede.

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

Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)

COEP en COOP is essensieel om cross-origin isolation te aktiveer, 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 is HSTS ’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

Permissions-Policy (voorheen Feature-Policy)

Permissions-Policy stel webontwikkelaars in staat om selektief sekere blaaierfunksies en APIs binne ’n dokument te aktiveer, deaktiveer of die gedrag daarvan aan te pas. Dit is die opvolger van die nou verouderde Feature-Policy header. Hierdie header help om die aanvalsoppervlakte te verminder deur toegang tot kragtige funksies wat misbruik kan word, te beperk.

Permissions-Policy: geolocation=(), camera=(), microphone=()

Algemene direktiewe:

DirektiefBeskrywing
accelerometerBeheer toegang tot die accelerometer-sensor
cameraBeheer toegang tot video-invoertoestelle (webcam)
geolocationBeheer toegang tot die Geolocation API
gyroscopeBeheer toegang tot die gyroskoop-sensor
magnetometerBeheer toegang tot die magnetometer-sensor
microphoneBeheer toegang tot audio-invoertoestelle
paymentBeheer toegang tot die Payment Request API
usbBeheer toegang tot die WebUSB API
fullscreenBeheer toegang tot die Fullscreen API
autoplayBeheer of media outomaties kan afspeel
clipboard-readBeheer toegang om klembordinhoud te lees
clipboard-writeBeheer toegang om na die klembord te skryf

Sintaksiswaardes:

  • () - Deaktiveer die funksie heeltemal
  • (self) - Laat die funksie slegs toe vir dieselfde oorsprong
  • * - Laat die funksie toe vir alle oorspronge
  • (self "https://example.com") - Laat toe vir dieselfde oorsprong en die gespesifiseerde domein

Voorbeeldkonfigurasies:

# Restrictive policy - disable most features
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=()

# Allow camera only from same origin
Permissions-Policy: camera=(self)

# Allow geolocation for same origin and a trusted partner
Permissions-Policy: geolocation=(self "https://maps.example.com")

Vanuit ’n sekuriteitsoptiek kan ontbrekende of te toegeeflike Permissions-Policy headers aanvallers (bv. via XSS of ingesette iframes) toelaat om kragtige blaaierfunksies te misbruik. Beperk altyd funksies tot die minimum wat jou toepassing benodig.

Header Name Casing Bypass

HTTP/1.1 definieer header-veldname as ongevoelig vir hoofletters/kleinletters (RFC 9110 §5.1). Desondanks is dit baie algemeen om aangepaste middleware, sekuriteitsfilters, of besigheidslogika te vind wat die letterlike header-naam wat ontvang is vergelyk sonder eers die hooflettergebruik te normaliseer (bv. header.equals("CamelExecCommandExecutable")). As daardie kontroles gevoelig vir hooflettergebruik uitgevoer word, kan ’n aanvaller dit eenvoudig omseil deur dieselfde header met ’n ander hooflettergebruik te stuur.

Tipiese situasies waar hierdie fout voorkom:

  • Aangepaste allow/deny-lyste wat probeer om “gevaarlike” interne headers te blokkeer voordat die versoek ’n sensitiewe komponent bereik.
  • In-huis implementasies van reverse-proxy pseudo-headers (bv. X-Forwarded-For sanitisering).
  • Frameworks wat management / debug endpunte blootstel en staatmaak op header-name vir verifikasie of kommandoseleksie.

Misbruik van die bypass

  1. Identifiseer ’n header wat server-side gefilter of gevalideer word (byvoorbeeld deur bronkode, dokumentasie, of foutboodskappe te lees).
  2. Stuur die dieselfde header met ’n ander hooflettergebruik (gemengde letters of hoofletters). Omdat HTTP-stakke gewoonlik headers eers kanoniseer nadat gebruikerkode geloop het, kan die kwesbare kontrole oorgeslaan word.
  3. As die downstream-komponent headers op ’n hoofletterongevoelige manier hanteer (meeste doen), sal dit die waarde wat deur die aanvaller beheer word aanvaar.

Voorbeeld: 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 met equals() gedoen, slegs die presiese naam in kleinletters 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 ongesif, wat lei tot remote command execution met die voorregte van die Camel-proses.

Opsporing & Mitigering

  • Normaliseer alle header-name na ’n enkele case (gewoonlik lowercase) voor die uitvoering van allow/deny comparisons.
  • Weier verdagte duplikate: indien beide Header: en HeAdEr: teenwoordig is, beskou dit as ’n anomalie.
  • Gebruik ’n positiewe allow-list wat na kanonisasie afgedwing word.
  • Beskerm management-endpunte met authentisering en netwerksegmentering.

Verwysings

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