Header HTTP speciali

Reading time: 12 minutes

Wordlists & Tools

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

Header per modificare la Location

Riscrivere origine IP:

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

Riscrivere location:

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

Hop-by-Hop headers

Un hop-by-hop header è un'intestazione progettata per essere elaborata e consumata dal proxy che sta 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 HEAD request con un body: il server non tiene conto che le HEAD non devono avere body e mantiene la connessione aperta fino al timeout.
• Alcuni server hanno restituito dati strani: dati casuali letti dal socket nella risposta, chiavi segrete o addirittura è servito a impedire al front-end di rimuovere certi valori di header.
• Ha anche causato un desync 0.CL perché il backend ha risposto con un 400 invece di un 100, ma il proxy front-end era pronto a inviare il body della richiesta iniziale; quindi lo invia e il backend lo interpreta come una nuova richiesta.
• Inviare una variazione come Expect: y 100-continue ha causato anch'essa il desync 0.CL.
• Un errore simile in cui il backend ha risposto con un 404 ha generato un desync CL.0 perché la richiesta malevola indicava un Content-Length; così il backend invia la richiesta malevola + i Content-Length byte 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, mentre il front-end pensava che fosse stata inviata una sola richiesta, quindi la seconda risposta viene inviata a una seconda vittima e la risposta di quella viene inviata alla successiva...

Per maggiori informazioni su HTTP Request Smuggling controlla:

HTTP Request Smuggling / HTTP Desync Attack

Intestazioni di Cache

Server Cache Headers:

• X-Cache nella risposta può avere il valore miss quando la richiesta non è stata cacheata e il valore hit quando lo è
• Comportamento simile nell'header Cf-Cache-Status
• Cache-Control indica se una risorsa viene cacheata e per quanto tempo: Cache-Control: public, max-age=1800
• Vary è spesso usato nella risposta per indicare header aggiuntivi che sono considerati parte della chiave di cache anche se normalmente non lo sono.
• Age definisce i secondi trascorsi da quando l'oggetto è nella cache del proxy.
• Server-Timing: cdn-cache; desc=HIT indica anch'esso che una risorsa è stata cacheata

Cache Poisoning and Cache Deception

Intestazioni Cache locali:

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

Condizionali

• Le richieste che usano gli header If-Modified-Since e If-Unmodified-Since riceveranno la risposta con i dati solo se l'header di risposta Last-Modified contiene un orario diverso.
• Le richieste condizionali che usano If-Match e If-None-Match utilizzano un valore Etag, quindi il web server invierà il contenuto della risposta se il dato (Etag) è cambiato. L'Etag viene preso dalla risposta HTTP.
• Il valore Etag è solitamente calcolato in base al contenuto della risposta. Per esempio, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" indica che l'Etag è lo Sha1 di 37 byte.

Range requests

• Accept-Ranges: Indica se il server supporta le range requests, e se sì 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-100 della risposta originale con codice 206 Partial Content. Ricorda inoltre di rimuovere l'header Accept-Encoding dalla richiesta.
• Questo può essere utile per ottenere una risposta con codice javascript riflesso arbitrario che altrimenti potrebbe essere escapato. Ma per abusarne dovresti iniettare questi header nella richiesta.
• If-Range: Crea una range request condizionale che viene soddisfatta solo se l'etag o la data fornita corrispondono alla risorsa remota. Utilizzato per evitare di scaricare due range da versioni incompatibili della risorsa.
• Content-Range: Indica dove, in un messaggio body completo, appartiene il messaggio parziale.

Informazioni sul corpo 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 umane destinate al pubblico, permettendo all'utente di differenziare secondo le proprie preferenze linguistiche.
• 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 trovi un qualche modo per ottenere queste info, potrebbe essere interessante.
Per esempio, una combinazione di Range ed Etag in una HEAD request può leakare il contenuto della pagina tramite richieste HEAD:

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

Informazioni sul server

• 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, potrebbe essere Allow: GET, POST, HEAD, indicando che la risorsa supporta questi metodi.
• Expect: Utilizzato dal client per comunicare aspettative che il server deve soddisfare affinché la richiesta venga processata con successo. Un uso comune è l'header Expect: 100-continue, che segnala l'intenzione del client di inviare un payload di grandi dimensioni. Il client si aspetta una risposta 100 (Continue) prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l'uso della rete attendendo la conferma del server.

Download

• L'header Content-Disposition nelle risposte HTTP indica se un file deve essere mostrato inline (all'interno della pagina) o trattato come attachment (scaricato). Per esempio:

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

Questo significa che il file chiamato "filename.jpg" è destinato a 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 contro attacchi DOM XSS. Trusted Types garantiscono che solo oggetti appositamente creati, conformi alle policy di sicurezza stabilite, possano essere usati in chiamate API web pericolose, 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

Questo 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, questa intestazione 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 le proprie autorizzazioni di incorporazione.

X-Frame-Options: DENY

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

CORP è cruciale per specificare quali risorse possono essere caricate dai siti web, mitigando i cross-site leaks. CORS, invece, permette un meccanismo più flessibile di condivisione cross-origin delle risorse, rilassando 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) e Cross-Origin Opener Policy (COOP)

COEP e COOP sono essenziali per abilitare l'isolamento cross-origin, 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 solo tramite connessioni HTTPS sicure, migliorando così la privacy e la sicurezza.

Strict-Transport-Security: max-age=3153600

Header Name Casing Bypass

HTTP/1.1 definisce i nomi dei campi header come insensibili alle maiuscole/minuscole (RFC 9110 §5.1). Tuttavia, è molto comune trovare middleware personalizzati, filtri di sicurezza o logica di business che confrontano il nome dell'header ricevuto letteralmente senza normalizzare prima il case (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 questo errore appare:

• Liste allow/deny personalizzate che cercano di bloccare header “pericolosi” interni prima che la richiesta raggiunga un componente sensibile.
• Implementazioni interne di pseudo-header dei reverse-proxy (es. X-Forwarded-For sanitisation).
• Framework che espongono endpoint di management / debug e si basano sui nomi degli header per l'autenticazione o la selezione dei comandi.

Abusing the bypass

1. Identificare un header che viene filtrato o validato server-side (per esempio leggendo il source code, la documentazione o i messaggi di errore).
2. Inviare lo stesso header con una capitalizzazione diversa (mixed-case o tutto maiuscolo). Poiché gli stack HTTP di solito canonicalizzano gli header solo dopo che il codice utente è stato eseguito, il controllo vulnerabile può essere saltato.
3. Se il componente a valle tratta gli header in modo case-insensitive (la maggior parte lo fa), accetterà il valore controllato dall'attaccante.

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

Nelle versioni vulnerabili di Apache Camel le route del Command Center cercano di bloccare le richieste non attendibili rimuovendo gli header CamelExecCommandExecutable e CamelExecCommandArgs. La comparazione veniva fatta con equals(), quindi venivano rimossi solo i nomi corrispondenti esattamente nel loro case.

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

Le intestazioni raggiungono il componente exec senza filtraggio, causando l'esecuzione remota di comandi con i privilegi del processo Camel.

Rilevamento e mitigazione

• Normalizzare tutti i nomi delle intestazioni in un unico case (di solito lowercase) prima di eseguire confronti allow/deny.
• Rifiutare duplicati sospetti: se sono presenti sia Header: che HeAdEr:, considerarlo un'anomalia.
• Usare una allow-list positiva applicata dopo la canonicalizzazione.
• Proteggere gli endpoint di gestione con autenticazione e segmentazione di rete.

Riferimenti

• 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