> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/fr/web/host-header/bypassing-validation-by-connection-state.md).
# Contournement de la validation par l’état de connexion
Notes sur le contournement de la validation par l’état de connexion pour les laboratoires de la PortSwigger Web Security Academy, incluant le workflow d’exploitation, les tests de payloads, la validation dans Burp Suite et le contexte de remédiation.
### Contournement de la validation de l’hôte via une attaque sur l’état de la connexion
**Description de la vulnérabilité**
Ce labo comporte une **vulnérabilité de type SSRF basée sur le routage via l’en-tête Host** en-tête, liée à une mauvaise gestion de l’état de la connexion côté serveur.
Bien que le serveur frontal semble valider correctement le `Host` en-tête, il fait une \*\*hypothèse\*\* dangereuse :
> Toutes les requêtes envoyées sur la même connexion TCP sont considérées comme fiables si la **première requête** est valide.
Cela permet d’injecter une requête malveillante ultérieure sur la même connexion, en contournant la validation initiale.
**Objectif du labo**
* Accéder au panneau d’administration interne :/ `HTTP://192.168.0.1/admin`
* Supprimer l’utilisateur **carlos**
**Observation initiale**
Une requête directe vers l’IP interne est bloquée :
```http
GET / HTTP/1.1
Host: 192.168.0.1
```
Le serveur rejette cette requête, ce qui confirme qu’une `Host` validation est en place **dès la première requête**.
**Opération : attaque sur l’état de la connexion**
L’idée est d’envoyer \*\*plusieurs requêtes sur la même connexion TCP\*\* :
1. Une première requête légitime vers l’hôte public (acceptée).
2. Une deuxième requête malveillante vers l’IP interne, envoyée **sur la même connexion**.
Dans Burp Suite, cela se fait en :
* Regrouper les requêtes
* En utilisant **Envoyer le groupe dans une seule connexion**
**Accès au panneau d’administration**
Une fois la connexion établie avec une requête valide, la requête suivante vers l’admin interne est acceptée :
```http
GET /admin HTTP/1.1
Host: 192.168.0.1
```
Le panneau d’administration interne devient alors accessible.
**Suppression de l’utilisateur**
La suppression de l’utilisateur nécessite une requête POST :
```http
POST /admin/delete HTTP/1.1
Host: 192.168.0.1
csrf=ppBVKn8wVrgZifEETHsn48Hykwiq8yFO&username=carlos
```
Réponse du serveur:
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/fr/web/host-header/bypassing-validation-by-connection-state.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
