Special HTTP headers

Reading time: 11 minutes

Wordlists & Tools

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

Headers to Change Location

Rewrite 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 (Controlla gli header hop-by-hop)

Rewrite location:

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

Hop-by-Hop headers

Un header hop-by-hop è un header progettato per essere elaborato e consumato dal proxy che gestisce attualmente la richiesta, a differenza 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

Cache Headers

Server Cache Headers:

• X-Cache nella risposta può avere il valore miss quando la richiesta non è stata memorizzata nella cache e il valore hit quando è memorizzata nella cache
• Comportamento simile nell'header Cf-Cache-Status
• Cache-Control indica se una risorsa è memorizzata nella cache e quando sarà la prossima volta che la risorsa sarà memorizzata di nuovo: Cache-Control: public, max-age=1800
• Vary è spesso usato nella risposta per indicare header aggiuntivi che sono trattati come parte della chiave della cache anche se normalmente non sono chiave.
• Age definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy.
• Server-Timing: cdn-cache; desc=HIT indica anche che una risorsa è stata memorizzata nella cache

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 risposta dovrebbe scadere: Expires: Wed, 21 Oct 2015 07:28:00 GMT
• Pragma: no-cache stesso di Cache-Control: no-cache
• Warning: L'header generale Warning contiene informazioni su possibili problemi con lo stato del messaggio. Più di un header Warning può apparire in una risposta. Warning: 110 anderson/1.3.37 "Response is stale"

Conditionals

• Le richieste che utilizzano questi header: If-Modified-Since e If-Unmodified-Since riceveranno una risposta con dati solo se l'header di risposta Last-Modified contiene un orario diverso.
• Le richieste condizionali che utilizzano If-Match e If-None-Match usano un valore Etag in modo che il server web invii il contenuto della risposta se i dati (Etag) sono cambiati. L'Etag è preso dalla risposta HTTP.
• Il valore Etag è solitamente calcolato in base al contenuto della risposta. Ad esempio, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" indica che l'Etag è il Sha1 di 37 byte.

Range requests

• Accept-Ranges: Indica se il server supporta le richieste di intervallo e, in tal caso, in quale unità l'intervallo può essere espresso. Accept-Ranges: <range-unit>
• Range: Indica la parte di un documento che il server dovrebbe restituire. Ad esempio, Range:80-100 restituirà i byte da 80 a 100 della risposta originale con un codice di stato di 206 Contenuto Parziale. Ricorda anche di rimuovere l'header Accept-Encoding dalla richiesta.
• Questo potrebbe essere utile per ottenere una risposta con codice JavaScript riflesso arbitrario che altrimenti potrebbe essere sfuggito. Ma per abusare di questo dovresti iniettare questi header nella richiesta.
• If-Range: Crea una richiesta di intervallo condizionale che viene soddisfatta solo se l'etag o la data forniti corrispondono alla risorsa remota. Usato per prevenire il download di due intervalli da versioni incompatibili della risorsa.
• Content-Range: Indica dove in un messaggio a corpo completo appartiene un messaggio parziale.

Message body information

• Content-Length: La dimensione della risorsa, in numero decimale di byte.
• Content-Type: Indica il tipo di media della risorsa
• Content-Encoding: Usato per specificare l'algoritmo di compressione.
• Content-Language: Descrive la/e lingua/e umana/e destinate al pubblico, in modo che consenta a un utente di differenziare in base alla lingua preferita dell'utente.
• 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 un modo per ottenere queste info, questo potrebbe essere interessante.
Ad esempio, una combinazione di Range e Etag in una richiesta HEAD può rivelare 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 rivelando che il SHA1 del byte 20 è ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Server Info

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

Controls

• Allow: Questo header è usato per comunicare i metodi HTTP che una risorsa può gestire. Ad esempio, potrebbe 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 elaborata con successo. Un caso d'uso comune coinvolge l'header Expect: 100-continue, che segnala che il client intende inviare un grande payload di dati. Il client cerca una risposta 100 (Continue) prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l'uso della rete attendendo la conferma del server.

Downloads

• L'header Content-Disposition nelle risposte HTTP indica se un file dovrebbe essere visualizzato inline (all'interno della pagina web) o trattato come un allegato (scaricato). Ad 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

Tipi Fidati

Imponendo i Tipi Fidati tramite CSP, le applicazioni possono essere protette contro attacchi DOM XSS. I Tipi Fidati garantiscono che solo oggetti specificamente progettati, conformi alle politiche di sicurezza stabilite, possano essere utilizzati in chiamate API web pericolose, garantendo così la sicurezza del 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 previene il MIME type sniffing, una pratica che potrebbe portare a vulnerabilità XSS. Garantisce che i browser rispettino i tipi MIME specificati dal server.

X-Content-Type-Options: nosniff

X-Frame-Options

Per combattere il clickjacking, questo header limita come i documenti possono essere incorporati nei tag <frame>, <iframe>, <embed> o <object>, raccomandando a tutti i documenti di specificare esplicitamente i loro permessi di incorporamento.

X-Frame-Options: DENY

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

CORP è fondamentale per specificare quali risorse possono essere caricate dai siti web, mitigando le perdite cross-site. CORS, d'altra parte, consente un meccanismo di condivisione delle risorse cross-origin più flessibile, allentando la politica di same-origin 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 il caricamento delle risorse cross-origin e l'interazione con le finestre cross-origin, rispettivamente.

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

HTTP Strict Transport Security (HSTS)

Infine, HSTS è una funzione di sicurezza che costringe 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 case-insensitive (RFC 9110 §5.1). Tuttavia, è molto comune trovare middleware personalizzati, filtri di sicurezza o logica aziendale che confrontano il nome dell'header letterale ricevuto senza normalizzare prima la capitalizzazione (ad esempio, header.equals("CamelExecCommandExecutable")). Se questi controlli vengono eseguiti case-sensitively, un attaccante può eluderli semplicemente inviando lo stesso header con una diversa capitalizzazione.

Situazioni tipiche in cui appare questo errore:

• Liste di autorizzazione/negazione personalizzate che cercano di bloccare header interni "pericolosi" prima che la richiesta raggiunga un componente sensibile.
• Implementazioni interne di pseudo-header di reverse-proxy (ad esempio, sanificazione di X-Forwarded-For).
• Framework che espongono endpoint di gestione / 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 convalidato lato server (ad esempio, leggendo il codice sorgente, la documentazione o i messaggi di errore).
2. Inviare lo stesso header con una diversa capitalizzazione (mixed-case o maiuscolo). Poiché gli stack HTTP di solito canonizzano gli header solo dopo che il codice utente è stato eseguito, il controllo vulnerabile può essere saltato.
3. Se il componente downstream 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 rotte del Command Center cercano di bloccare richieste non attendibili rimuovendo gli header CamelExecCommandExecutable e CamelExecCommandArgs. Il confronto è stato effettuato con equals(), quindi solo i nomi esatti in minuscolo sono stati rimossi.

# 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 non filtrate, risultando in un'esecuzione di comandi remoti con i privilegi del processo Camel.

Rilevamento e Mitigazione

• Normalizza tutti i nomi delle intestazioni a un singolo caso (di solito minuscolo) prima di eseguire confronti di autorizzazione/rifiuto.
• Rifiuta duplicati sospetti: se sono presenti sia Header: che HeAdEr:, trattalo come un'anomalia.
• Utilizza una lista di autorizzazione positiva applicata dopo la canonicalizzazione.
• Proteggi gli endpoint di gestione con autenticazione e segmentazione della 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