Header HTTP speciali

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Wordlists & Tools

Headers per cambiare la Location

Riscrivi IP source:

  • 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 (Controllare gli hop-by-hop headers)

Riscrivi location:

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

Hop-by-Hop headers

Un hop-by-hop header è un header progettato per essere processato e consumato dal proxy che sta attualmente gestendo la richiesta, al contrario di un header end-to-end.

  • Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

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

HTTP Request Smuggling / HTTP Desync Attack

L’header Expect

È possibile che il client invii l’header Expect: 100-continue e che il server risponda con HTTP/1.1 100 Continue per permettere al client di continuare a inviare il body della richiesta. Tuttavia, alcuni proxy non gradiscono questo header.

Risultati interessanti di Expect: 100-continue:

  • Inviare una richiesta HEAD con un body: il server non ha considerato che le richieste HEAD non hanno body e mantiene la connessione aperta fino al timeout.
  • Alcuni server hanno inviato dati strani: dati casuali letti dal socket nella risposta, chiavi segrete o addirittura ha permesso di impedire al front-end di rimuovere valori degli header.
  • Ha anche causato una desync 0.CL perché il backend ha risposto con un 400 invece di un 100, ma il proxy front-end era pronto ad inviare il body della richiesta iniziale, quindi lo invia e il backend lo interpreta come una nuova richiesta.
  • L’invio di una variante tipo Expect: y 100-continue ha causato anch’essa la desync 0.CL.
  • Un errore simile in cui il backend ha risposto con un 404 ha generato una desync CL.0 perché la richiesta malevola indicava un Content-Length, così il backend invia la richiesta malevola + i byte indicati dal Content-Length della richiesta successiva (di una vittima); questo desincronizza la coda perché il backend invia la risposta 404 per la richiesta malevola + la risposta delle richieste della vittima, ma il front-end pensava che fosse stata inviata solo 1 richiesta, quindi la seconda risposta viene inviata a una seconda vittima e la risposta di quella viene inviata alla successiva…

Per più info su HTTP Request Smuggling consulta:

HTTP Request Smuggling / HTTP Desync Attack

Cache Headers

Server Cache Headers:

  • X-Cache nella response può avere il valore miss quando la richiesta non è stata cached e il valore hit quando è cached
  • Comportamento simile nell’header Cf-Cache-Status
  • Cache-Control indica se una risorsa è in cache e quando sarà nuovamente disponibile dalla cache: Cache-Control: public, max-age=1800
  • Vary è spesso usato nella response per indicare header aggiuntivi che sono trattati come parte della cache key anche se normalmente non sono considerati.
  • Age definisce i secondi in cui l’oggetto è stato nella cache del proxy.
  • Server-Timing: cdn-cache; desc=HIT indica anch’esso che una risorsa è stata cached

Cache Poisoning and Cache Deception

Local Cache headers:

  • Clear-Site-Data: Header per indicare la cache che dovrebbe essere rimossa: Clear-Site-Data: "cache", "cookies"
  • Expires: Contiene la data/ora in cui la response dovrebbe scadere: Expires: Wed, 21 Oct 2015 07:28:00 GMT
  • Pragma: no-cache equivalente a Cache-Control: no-cache
  • Warning: L’header generale HTTP Warning contiene informazioni su possibili problemi con lo stato del messaggio. Possono apparire più di un header Warning in una response. Warning: 110 anderson/1.3.37 "Response is stale"

Conditionals

  • Le richieste che usano questi header: If-Modified-Since e If-Unmodified-Since riceveranno dati solo se l’header di response Last-Modified contiene un orario diverso.
  • Le richieste condizionali che usano If-Match e If-None-Match usano un valore Etag in modo che il web server invii il contenuto della response se i dati (Etag) sono cambiati. L’Etag viene preso dalla HTTP response.
  • Il valore Etag è solitamente calcolato basandosi sul contenuto della response. Per esempio, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" indica che l’Etag è lo Sha1 di 37 bytes.

Range requests

  • Accept-Ranges: Indica se il server supporta le range requests, e in quale unità la range può essere espressa. Accept-Ranges: <range-unit>
  • Range: Indica la parte di un documento che il server dovrebbe restituire. Per esempio, Range:80-100 restituirà i byte 80 a 100 della response originale con status code 206 Partial Content. Ricorda anche di rimuovere l’header Accept-Encoding dalla richiesta.
  • Questo può essere utile per ottenere una response con codice JavaScript riflesso arbitrario che altrimenti verrebbe escapato. Ma per abusarne dovresti poter injectare questi header nella richiesta.
  • If-Range: Crea una range request condizionale che viene soddisfatta solo se l’etag o la data forniti corrispondono alla risorsa remota. Usata per evitare di scaricare due range da versioni incompatibili della risorsa.
  • Content-Range: Indica dove in un body completo appartiene un messaggio parziale.

Informazioni sul body del messaggio

  • Content-Length: La dimensione della risorsa, in numero decimale di byte.
  • Content-Type: Indica il media type della risorsa
  • Content-Encoding: Usato per specificare l’algoritmo di compressione.
  • Content-Language: Descrive la/le lingua(e) umana(e) destinatarie, così da permettere all’utente di differenziare in base alla lingua preferita.
  • Content-Location: Indica una posizione alternativa per i dati restituiti.

Dal punto di vista di un pentest queste informazioni sono solitamente “inutili”, ma se la risorsa è protetta da un 401 o 403 e riesci a trovare qualche modo per ottenere queste info, questo potrebbe essere interessante.
Per esempio una combinazione di Range e Etag in una HEAD request può leakare il contenuto della pagina via HEAD requests:

  • Una richiesta con l’header Range: bytes=20-20 e con una response che contiene ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" sta leakando che lo SHA1 del byte 20 è ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Server Info

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

Controlli

  • Allow: Questo header è usato per comunicare i metodi HTTP che una risorsa può gestire. Per esempio, può essere specificato come Allow: GET, POST, HEAD, indicando che la risorsa supporta questi metodi.
  • Expect: Utilizzato dal client per comunicare le aspettative che il server deve soddisfare affinché la richiesta venga processata con successo. Un caso comune è l’header Expect: 100-continue, che segnala l’intenzione del client di inviare un payload di grandi dimensioni. Il client attende una risposta 100 (Continue) prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l’uso della rete aspettando la conferma del server.

Downloads

  • L’header Content-Disposition nelle HTTP responses indica se un file dovrebbe essere mostrato inline (all’interno della pagina) o trattato come un attachment (scaricato). Per esempio:
Content-Disposition: attachment; filename="filename.jpg"

Questo significa che il file chiamato “filename.jpg” è destinato ad essere scaricato e salvato.

Intestazioni di sicurezza

Content Security Policy (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Applicando Trusted Types tramite CSP, le applicazioni possono essere protette dagli attacchi DOM XSS. Trusted Types garantiscono che solo oggetti appositamente creati, conformi alle politiche di sicurezza stabilite, possano essere utilizzati in chiamate pericolose alle web API, proteggendo così il codice JavaScript per impostazione predefinita.

// 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

Questa header impedisce il MIME type sniffing, una pratica che potrebbe portare a vulnerabilità XSS. Garantisce che i browser rispettino i MIME types specificati dal server.

X-Content-Type-Options: nosniff

X-Frame-Options

Per contrastare il clickjacking, questo header limita il modo in cui i documenti possono essere incorporati nei tag <frame>, <iframe>, <embed> o <object>, raccomandando a tutti i documenti di specificare esplicitamente i propri permessi di incorporamento.

X-Frame-Options: DENY

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

CORP è fondamentale per specificare quali risorse possono essere caricate dai siti web, mitigando i cross-site leak. CORS, invece, permette un meccanismo più flessibile di cross-origin resource sharing, allentando la same-origin policy in determinate condizioni.

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 e COOP sono essenziali per abilitare il cross-origin isolation, riducendo significativamente il rischio di attacchi simili a Spectre. Controllano rispettivamente il caricamento di risorse cross-origin e l’interazione con finestre cross-origin.

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

HTTP Strict Transport Security (HSTS)

Infine, HSTS è una funzionalità di sicurezza che obbliga i browser a comunicare con i server esclusivamente tramite connessioni HTTPS sicure, migliorando così privacy e sicurezza.

Strict-Transport-Security: max-age=3153600

Permissions-Policy (formerly Feature-Policy)

Permissions-Policy permette agli sviluppatori web di abilitare, disabilitare o modificare selettivamente il comportamento di alcune funzionalità del browser e delle API all’interno di un documento. È il successore dell’header ora deprecato Feature-Policy. Questo header aiuta a ridurre la superficie d’attacco limitando l’accesso a funzionalità potenti che potrebbero essere abusate.

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

Direttive comuni:

DirectiveDescrizione
accelerometerControlla l’accesso al sensore accelerometro
cameraControlla l’accesso ai dispositivi di input video (webcam)
geolocationControlla l’accesso alla Geolocation API
gyroscopeControlla l’accesso al sensore giroscopio
magnetometerControlla l’accesso al sensore magnetometro
microphoneControlla l’accesso ai dispositivi di input audio
paymentControlla l’accesso alla Payment Request API
usbControlla l’accesso alla WebUSB API
fullscreenControlla l’accesso alla Fullscreen API
autoplayControlla se i media possono essere riprodotti automaticamente
clipboard-readControlla l’accesso alla lettura del contenuto degli appunti
clipboard-writeControlla l’accesso alla scrittura negli appunti

Valori di sintassi:

  • () - Disabilita completamente la funzionalità
  • (self) - Consente la funzionalità solo per la stessa origine
  • * - Consente la funzionalità per tutte le origini
  • (self "https://example.com") - Consente per la stessa origine e il dominio specificato

Esempi di configurazione:

# 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")

Dal punto di vista della sicurezza, header Permissions-Policy mancanti o eccessivamente permissivi possono permettere agli attaccanti (ad esempio, tramite XSS o iframe incorporati) di abusare di potenti funzionalità del browser. Restringi sempre le funzionalità al minimo necessario per la tua applicazione.

Bypass del nome header tramite casing

HTTP/1.1 definisce i field-names degli header come insensibili alle maiuscole/minuscole (RFC 9110 §5.1). Tuttavia, è molto comune trovare middleware personalizzati, filtri di sicurezza o logica applicativa che confrontano il nome letterale dell’header ricevuto senza normalizzare prima la capitalizzazione (es. header.equals("CamelExecCommandExecutable")). Se questi controlli vengono eseguiti sensibili alle maiuscole/minuscole, un attaccante può aggirarli semplicemente inviando lo stesso header con una capitalizzazione diversa.

Situazioni tipiche in cui appare questo errore:

  • Allow/deny list personalizzate che cercano di bloccare header interni “pericolosi” prima che la request raggiunga un componente sensibile.
  • Implementazioni interne di pseudo-header di reverse-proxy (es. X-Forwarded-For sanitizzazione).
  • Framework che espongono endpoint di gestione / debug e si affidano ai nomi degli header per autenticazione o selezione dei comandi.

Sfruttare il bypass

  1. Identifica un header che viene filtrato o validato lato server (per esempio, leggendo il codice sorgente, la documentazione o i messaggi di errore).
  2. Invia lo stesso header con una capitalizzazione diversa (mixed-case o upper-case). Poiché gli stack HTTP solitamente canonicalizzano gli header solo dopo l’esecuzione del codice utente, il controllo vulnerabile può essere saltato.
  3. Se il componente a valle tratta gli header in modo insensibile alle maiuscole/minuscole (la maggior parte lo fa), accetterà il valore controllato dall’attaccante.

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

Nelle versioni vulnerabili di Apache Camel le route del Command Center cercano di bloccare le richieste non fidate rimuovendo gli header CamelExecCommandExecutable e CamelExecCommandArgs. Il confronto veniva effettuato con equals(), quindi venivano rimossi solo i nomi esattamente identici (stessa capitalizzazione).

# 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: /"

Gli header raggiungono il componente exec senza filtraggio, causando l’esecuzione remota di comandi con i privilegi del processo Camel.

Rilevamento e mitigazione

  • Normalizza tutti i nomi degli header in un unico case (di solito lowercase) prima di effettuare confronti allow/deny.
  • Rifiuta duplicati sospetti: se sono presenti sia Header: che HeAdEr:, considerali un’anomalia.
  • Usa una allow-list positiva applicata dopo la canonicalisation.
  • Proteggi gli endpoint di management con autenticazione e segmentazione di rete.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks