En-têtes HTTP spéciaux

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d’abonnement !

Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.

Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

En-têtes pour réécrire l’emplacement

Réécrire la source 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 (Vérifier les hop-by-hop headers)

Réécrire emplacement :

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 qui gère actuellement la requête, contrairement à un 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

Il est possible pour le client d’envoyer l’en-tête Expect: 100-continue et ensuite le serveur peut répondre HTTP/1.1 100 Continue pour permettre au client de continuer à envoyer le corps de la requête. Cependant, certains proxies n’aiment pas vraiment cet en-tête.

Résultats intéressants de Expect: 100-continue :

Envoyer une requête HEAD avec un corps : le serveur ne prend pas en compte que les requêtes HEAD n’ont pas de corps et garde la connexion ouverte jusqu’à l’expiration du timeout.
D’autres serveurs ont renvoyé des données étranges : des données aléatoires lues depuis le socket dans la réponse, des clés secrètes, ou cela a même permis d’empêcher le front-end de supprimer des valeurs d’en-têtes.
Cela a aussi provoqué une désynchronisation 0.CL parce que le backend a répondu avec un 400 au lieu d’un 100 ; le proxy front-end était prêt à envoyer le corps de la requête initiale, donc il l’envoie et le backend l’interprète comme une nouvelle requête.
L’envoi d’une variation Expect: y 100-continue a aussi provoqué la désynchronisation 0.CL.
Une erreur similaire où le backend a répondu avec un 404 a généré une désynchronisation CL.0 parce que la requête malveillante indique un Content-Length. Le backend envoie donc la requête malveillante plus les octets correspondant au Content-Length de la requête suivante (d’une victime) ; cela désynchronise la file : le backend envoie la réponse 404 pour la requête malveillante plus la réponse des requêtes de la victime, mais le front-end pensait qu’une seule requête avait été envoyée. Ainsi, la deuxième réponse est envoyée à une seconde requête de victime, et la réponse de celle-ci est envoyée à la suivante…

Pour plus d’infos sur HTTP Request Smuggling vérifiez :

HTTP Request Smuggling / HTTP Desync Attack

En-têtes de cache

En-têtes de cache côté serveur :

X-Cache dans la réponse peut avoir la valeur miss lorsque la requête n’a pas été mise en cache et la valeur hit lorsqu’elle l’est
Comportement similaire dans l’en-tête Cf-Cache-Status
Cache-Control indique si une ressource est mise en cache et quand elle expirera : Cache-Control: public, max-age=1800
Vary est souvent utilisé dans la réponse pour indiquer des en-têtes supplémentaires qui sont traités comme faisant partie de la clé de cache, même s’ils sont normalement non indexés.
Age définit le temps en secondes pendant lequel l’objet est resté dans le cache du proxy.
Server-Timing: cdn-cache; desc=HIT indique aussi 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 à supprimer: 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 liés au statut 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 requêtes utilisant ces en-têtes : If-Modified-Since et If-Unmodified-Since recevront des données seulement si l’en-tête de réponse Last-Modified contient une heure différente.
Les requêtes conditionnelles utilisant If-Match et If-None-Match emploient une valeur Etag : le serveur renverra le contenu si les données (Etag) ont changé. Le Etag est extrait de la réponse HTTP.
La valeur Etag est généralement calculée à partir du contenu de la réponse. Par exemple, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" indique que l’Etag est le Sha1 de 37 octets.

Requêtes Range

Accept-Ranges: indique si le serveur supporte les range requests, 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 renvoyer. Par exemple, Range:80-100 retournera les octets 80 à 100 de la réponse originale avec un code 206 Partial Content. Pensez aussi à retirer l’en-tête Accept-Encoding de la requête.
Cela peut être utile pour obtenir une réponse contenant du code JavaScript reflété arbitrairement qui sinon serait échappé. Mais pour abuser de cela, il faudrait injecter ces en-têtes dans la requête.
If-Range: crée une requête de plage conditionnelle qui n’est satisfaite que si l’etag ou la date donnée correspond à la ressource distante. Utilisé pour éviter de télécharger deux plages provenant de versions incompatibles de la ressource.
Content-Range: indique où, dans un message complet, une réponse partielle 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 MIME 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, ce qui permet à un utilisateur de choisir selon sa langue préférée.
Content-Location: indique un emplacement alternatif pour les données retournées.

D’un point de vue 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 infos, cela peut être intéressant.
Par exemple, une combinaison de Range et Etag dans une requête HEAD peut leak le contenu de la page via des requêtes HEAD:

Une requête avec l’en-tête Range: bytes=20-20 et avec une réponse contenant ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" is leaking that the SHA1 of byte 20 is ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Infos 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é Allow: GET, POST, HEAD, indiquant que la ressource supporte ces méthodes.
Expect: utilisé par le client pour exprimer des attentes que le serveur doit satisfaire pour que la requête soit traitée correctement. Un cas d’usage fréquent est Expect: 100-continue, qui signale que le client a l’intention d’envoyer une grosse charge de données. Le client attend une réponse 100 (Continue) avant de poursuivre l’envoi. 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) ou traité comme une attachment (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é

Content Security Policy (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

En appliquant Trusted Types via CSP, les applications peuvent être protégées contre les attaques DOM XSS. Trusted Types garantissent que seuls des objets spécialement 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 des types MIME, une pratique qui pourrait mener à 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 que tous les documents spécifient explicitement leurs autorisations d’intégration.

X-Frame-Options: DENY

CORP est crucial pour spécifier quelles ressources peuvent être chargées par les sites web, en atténuant les cross-site leaks. CORS, en revanche, permet un mécanisme plus flexible de cross-origin resource sharing, en assouplissant la same-origin policy sous certaines conditions.

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

Politique d’intégration Cross-Origin (COEP) et Politique d’ouverture Cross-Origin (COOP)

COEP et COOP sont essentiels pour activer l’isolation cross-origin, réduisant significativement le risque d’attaques de type Spectre. Ils contrôlent respectivement le chargement des ressources cross-origin et l’interaction avec les fenêtres cross-origin.

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

Permissions-Policy (anciennement Feature-Policy)

Permissions-Policy permet aux développeurs web d’activer, de désactiver ou de modifier de manière sélective le comportement de certaines fonctionnalités du navigateur et des API au sein d’un document. C’est le successeur de l’en-tête désormais obsolète Feature-Policy. Cet en-tête aide à réduire la surface d’attaque en restreignant l’accès à des fonctionnalités puissantes susceptibles d’être abusées.

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

Directives courantes :

Directive	Description
`accelerometer`	Contrôle l’accès au capteur d’accéléromètre
`camera`	Contrôle l’accès aux périphériques d’entrée vidéo (webcam)
`geolocation`	Contrôle l’accès à l’API Geolocation
`gyroscope`	Contrôle l’accès au gyroscope
`magnetometer`	Contrôle l’accès au magnétomètre
`microphone`	Contrôle l’accès aux périphériques d’entrée audio
`payment`	Contrôle l’accès à l’API Payment Request
`usb`	Contrôle l’accès à l’API WebUSB
`fullscreen`	Contrôle l’accès à l’API Fullscreen
`autoplay`	Contrôle si les médias peuvent être lus automatiquement
`clipboard-read`	Contrôle l’accès à la lecture du contenu du presse-papiers
`clipboard-write`	Contrôle l’accès à l’écriture du contenu du presse-papiers

Valeurs de syntaxe :

() - Désactive entièrement la fonctionnalité
(self) - Autorise la fonctionnalité uniquement pour la même origine
* - Autorise la fonctionnalité pour toutes les origines
(self "https://example.com") - Autorise pour la même origine et le domaine spécifié

Exemples de configurations :

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

D’un point de vue sécurité, l’absence ou la permissivité excessive des en-têtes Permissions-Policy peut permettre à des attaquants (par ex. via XSS ou iframes intégrées) d’abuser de fonctionnalités puissantes du navigateur. Restreignez toujours les fonctionnalités au strict minimum nécessaire pour votre application.

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 de la logique métier qui comparent le nom d’en-tête littéral reçu sans normaliser la casse au préalable (par ex. header.equals("CamelExecCommandExecutable")). Si ces vérifications sont effectuées de manière sensible à 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 personnalisées allow/deny qui tentent de bloquer des 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 ex. X-Forwarded-For) et leur assainissement.
Frameworks qui exposent des endpoints de gestion / debug et qui s’appuient sur les noms d’en-tête pour l’authentification ou la sélection de commandes.

Exploitation du contournement

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).
Envoyer le même en-tête avec une casse différente (casse mixte ou en majuscules). Parce que les piles HTTP normalisent généralement les en-têtes seulement après l’exécution du code utilisateur, la vérification vulnérable peut être évitée.
Si le composant en aval traite les en-têtes de manière insensible à la casse (comme c’est le cas pour la plupart), il acceptera la valeur contrôlée par l’attaquant.

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

Dans des versions vulnérables d’Apache Camel, les routes du Command Center tentent de bloquer les requêtes non fiables en supprimant les en-têtes CamelExecCommandExecutable et CamelExecCommandArgs. La comparaison se faisait 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 être filtrés, 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êtes dans une casse unique (généralement minuscules) avant d’effectuer les comparaisons allow/deny.
Rejetez les doublons suspects : si Header: et HeAdEr: sont tous deux présents, considérez cela comme une anomalie.
Utilisez une allow-list positive appliquée après la canonicalisation.
Protégez les endpoints de gestion par authentification et segmentation réseau.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d’abonnement !

Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.

Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

HackTricks