# En-têtes HTTP spéciaux

{{#include ../../banners/hacktricks-training.md}}

## Listes de mots & Outils

- [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
- [https://github.com/rfc-st/humble](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`

{{#ref}}
../../pentesting-web/abusing-hop-by-hop-headers.md
{{#endref}}

## HTTP Request Smuggling

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

{{#ref}}
../../pentesting-web/http-request-smuggling/
{{#endref}}

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

{{#ref}}
../../pentesting-web/cache-deception/
{{#endref}}

**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) <a href="#csp" id="csp"></a>


{{#ref}}
../../pentesting-web/content-security-policy-csp-bypass/
{{#endref}}

### **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.
```javascript
// 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;');
});
}
```

```javascript
// 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.
```bash
# 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://www.offsec.com/blog/cve-2025-27636/)
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
- [https://web.dev/articles/security-headers](https://web.dev/articles/security-headers)

{{#include ../../banners/hacktricks-training.md}}