En-têtes HTTP spéciaux

Reading time: 11 minutes

Listes de mots & Outils

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

En-têtes pour changer la localisation

Réécrire 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 (Vérifiez les en-têtes hop-by-hop)

Réécrire localisation :

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

En-têtes Hop-by-Hop

Un en-tête hop-by-hop est un en-tête conçu pour être traité et consommé par le proxy gérant actuellement la demande, contrairement à un en-tête de bout en bout.

• Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

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

HTTP Request Smuggling / HTTP Desync Attack

En-têtes de cache

En-têtes de cache du serveur :

• X-Cache dans la réponse peut avoir la valeur miss lorsque la demande n'a pas été mise en cache et la valeur hit lorsqu'elle est mise en cache
• Comportement similaire dans l'en-tête Cf-Cache-Status
• Cache-Control indique si une ressource est mise en cache et quand la ressource sera mise en cache à nouveau : Cache-Control: public, max-age=1800
• Vary est souvent utilisé dans la réponse pour indiquer des en-têtes supplémentaires qui sont considérés comme partie de la clé de cache même s'ils ne sont normalement pas clés.
• Age définit le temps en secondes que l'objet a passé dans le cache proxy.
• Server-Timing: cdn-cache; desc=HIT indique également qu'une ressource a été mise en cache

Cache Poisoning and Cache Deception

En-têtes de cache locaux :

• Clear-Site-Data: En-tête pour indiquer le cache qui doit être supprimé : Clear-Site-Data: "cache", "cookies"
• Expires: Contient la date/heure à laquelle la réponse doit expirer : Expires: Wed, 21 Oct 2015 07:28:00 GMT
• Pragma: no-cache identique à Cache-Control: no-cache
• Warning: L'en-tête HTTP général Warning contient des informations sur d'éventuels problèmes avec l'état du message. Plus d'un en-tête Warning peut apparaître dans une réponse. Warning: 110 anderson/1.3.37 "Response is stale"

Conditionnels

• Les demandes utilisant ces en-têtes : If-Modified-Since et If-Unmodified-Since seront répondues avec des données uniquement si l'en-tête de réponse Last-Modified contient un temps différent.
• Les demandes conditionnelles utilisant If-Match et If-None-Match utilisent une valeur Etag afin que le serveur web envoie le contenu de la réponse si les données (Etag) ont changé. L'Etag est pris de la réponse HTTP.
• La valeur Etag est généralement calculée en fonction du contenu de la réponse. Par exemple, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" indique que l'Etag est le Sha1 de 37 octets.

Requêtes de plage

• Accept-Ranges : Indique si le serveur prend en charge les requêtes de plage, et si oui, dans quelle unité la plage peut être exprimée. Accept-Ranges: <range-unit>
• Range : Indique la partie d'un document que le serveur doit retourner. Par exemple, Range:80-100 retournera les octets 80 à 100 de la réponse originale avec un code d'état de 206 Partial Content. N'oubliez pas de supprimer l'en-tête Accept-Encoding de la demande.
• Cela pourrait être utile pour obtenir une réponse avec du code javascript réfléchi arbitraire qui pourrait autrement être échappé. Mais pour en abuser, vous auriez besoin d'injecter ces en-têtes dans la demande.
• If-Range : Crée une demande de plage conditionnelle qui n'est remplie que si l'etag ou la date donnée correspond à la ressource distante. Utilisé pour éviter de télécharger deux plages de versions incompatibles de la ressource.
• Content-Range : Indique où dans un message complet un message partiel appartient.

Informations sur le corps du message

• Content-Length : La taille de la ressource, en nombre décimal d'octets.
• Content-Type : Indique le type de média de la ressource
• Content-Encoding : Utilisé pour spécifier l'algorithme de compression.
• Content-Language : Décrit la ou les langues humaines destinées au public, afin de permettre à un utilisateur de différencier selon la langue préférée de l'utilisateur.
• Content-Location : Indique un emplacement alternatif pour les données retournées.

Du point de vue d'un pentest, ces informations sont généralement "inutiles", mais si la ressource est protégée par un 401 ou 403 et que vous pouvez trouver un moyen d'obtenir ces informations, cela pourrait être intéressant.
Par exemple, une combinaison de Range et Etag dans une demande HEAD peut révéler le contenu de la page via des demandes HEAD :

• Une demande avec l'en-tête Range: bytes=20-20 et avec une réponse contenant ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" révèle que le SHA1 de l'octet 20 est ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Informations sur le serveur

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

Contrôles

• Allow : Cet en-tête est utilisé pour communiquer les méthodes HTTP qu'une ressource peut gérer. Par exemple, il peut être spécifié comme Allow: GET, POST, HEAD, indiquant que la ressource prend en charge ces méthodes.
• Expect : Utilisé par le client pour transmettre des attentes que le serveur doit satisfaire pour que la demande soit traitée avec succès. Un cas d'utilisation courant implique l'en-tête Expect: 100-continue, qui signale que le client a l'intention d'envoyer une grande charge de données. Le client attend une réponse 100 (Continue) avant de procéder à la transmission. Ce mécanisme aide à optimiser l'utilisation du réseau en attendant la confirmation du serveur.

Téléchargements

• L'en-tête Content-Disposition dans les réponses HTTP indique si un fichier doit être affiché inline (dans la page web) ou traité comme une pièce jointe (téléchargé). Par exemple :

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

Cela signifie que le fichier nommé "filename.jpg" est destiné à être téléchargé et enregistré.

En-têtes de sécurité

Politique de sécurité du contenu (CSP)

Content Security Policy (CSP) Bypass

Types de confiance

En appliquant les Types de confiance via CSP, les applications peuvent être protégées contre les attaques XSS DOM. Les Types de confiance garantissent que seuls des objets spécifiquement conçus, conformes aux politiques de sécurité établies, peuvent être utilisés dans des appels d'API web dangereux, sécurisant ainsi le code JavaScript par défaut.

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

Cet en-tête empêche le sniffing de type MIME, une pratique qui pourrait conduire à des vulnérabilités XSS. Il garantit que les navigateurs respectent les types MIME spécifiés par le serveur.

X-Content-Type-Options: nosniff

X-Frame-Options

Pour lutter contre le clickjacking, cet en-tête restreint la manière dont les documents peuvent être intégrés dans les balises <frame>, <iframe>, <embed> ou <object>, recommandant à tous les documents de spécifier explicitement leurs autorisations d'intégration.

X-Frame-Options: DENY

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

CORP est crucial pour spécifier quelles ressources peuvent être chargées par les sites web, atténuant les fuites inter-sites. CORS, en revanche, permet un mécanisme de partage de ressources inter-origines plus flexible, assouplissant la politique de même origine dans certaines conditions.

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

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

COEP et COOP sont essentiels pour permettre l'isolement entre origines, réduisant considérablement le risque d'attaques similaires à Spectre. Ils contrôlent le chargement des ressources entre origines et l'interaction avec les fenêtres entre origines, respectivement.

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

HTTP Strict Transport Security (HSTS)

Enfin, HSTS est une fonctionnalité de sécurité qui oblige les navigateurs à communiquer avec les serveurs uniquement via des connexions HTTPS sécurisées, améliorant ainsi la confidentialité et la sécurité.

Strict-Transport-Security: max-age=3153600

Contournement de la casse des noms d'en-tête

HTTP/1.1 définit les noms de champs d'en-tête comme insensibles à la casse (RFC 9110 §5.1). Néanmoins, il est très courant de trouver des middleware personnalisés, des filtres de sécurité ou une logique métier qui comparent le nom d'en-tête littéral reçu sans normaliser la casse au préalable (par exemple, header.equals("CamelExecCommandExecutable")). Si ces vérifications sont effectuées sensiblement à la casse, un attaquant peut les contourner simplement en envoyant le même en-tête avec une capitalisation différente.

Situations typiques où cette erreur apparaît :

• Listes d'autorisation/refus personnalisées qui essaient de bloquer les en-têtes internes "dangereux" avant que la requête n'atteigne un composant sensible.
• Implémentations internes de pseudo-en-têtes de reverse proxy (par exemple, la sanitation de X-Forwarded-For).
• Frameworks qui exposent des points de terminaison de gestion / débogage et s'appuient sur les noms d'en-tête pour l'authentification ou la sélection de commandes.

Abus du contournement

1. Identifier un en-tête qui est filtré ou validé côté serveur (par exemple, en lisant le code source, la documentation ou les messages d'erreur).
2. Envoyer le même en-tête avec une casse différente (casse mixte ou majuscule). Parce que les piles HTTP canonisent généralement les en-têtes seulement après que le code utilisateur a été exécuté, la vérification vulnérable peut être contournée.
3. Si le composant en aval traite les en-têtes de manière insensible à la casse (la plupart le font), il acceptera la valeur contrôlée par l'attaquant.

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

Dans les versions vulnérables d'Apache Camel, les routes du Command Center essaient de bloquer les requêtes non fiables en supprimant les en-têtes CamelExecCommandExecutable et CamelExecCommandArgs. La comparaison était effectuée avec equals(), donc seuls les noms en minuscules exacts étaient supprimés.

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

Les en-têtes atteignent le composant exec sans filtrage, ce qui entraîne une exécution de commandes à distance avec les privilèges du processus Camel.

Détection et atténuation

• Normalisez tous les noms d'en-tête en une seule casse (généralement en minuscules) avant d'effectuer des comparaisons d'autorisation/refus.
• Rejetez les doublons suspects : si à la fois Header: et HeAdEr: sont présents, considérez cela comme une anomalie.
• Utilisez une liste d'autorisation positive appliquée après la canonicalisation.
• Protégez les points de gestion avec une authentification et une segmentation réseau.

Références

• CVE-2025-27636 – RCE dans Apache Camel via contournement de la casse des en-têtes (blog OffSec)
• 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