-
Notifications
You must be signed in to change notification settings - Fork 0
HTTP
Synthèse complète pour la formation cybersécurité Parcours : Pre Security > How The Web Works
HTTP est le protocole sur lequel repose l'intégralité du web. Chaque fois que tu charges une page, soumets un formulaire, ou utilises une application web, des requêtes HTTP sont échangées entre ton navigateur et un serveur. Comprendre HTTP c'est comprendre comment fonctionne le web, comment les applications communiquent, et comment la majorité des attaques web s'opèrent.
HTTP signifie HyperText Transfer Protocol.
C'est le protocole de communication utilisé par les navigateurs web pour échanger des données avec les serveurs web. Il opère à la couche 7 (Application) du modèle OSI et utilise TCP comme protocole de transport.
HTTP vs HTTPS HTTPS est HTTP avec une couche de chiffrement TLS par-dessus. Le contenu des échanges est identique, mais chiffré en transit. HTTP utilise le port 80. HTTPS utilise le port 443.
Une URL (Uniform Resource Locator) est l'adresse complète d'une ressource sur le web. Elle contient plusieurs composants.
http://user:password@tryhackme.com:80/page?search=hello#section
| | | | | | |
Schéma Credentials Domaine Port Chemin Paramètres Ancre
| Composant | Description | Exemple |
|---|---|---|
| Schéma | Protocole utilisé | http, https, ftp |
| Credentials | Authentification (rare dans les URLs modernes) | user:password |
| Domaine | Nom du serveur cible | tryhackme.com |
| Port | Port de connexion (optionnel si standard) | 80, 443 |
| Chemin | Ressource demandée sur le serveur | /page |
| Query String | Paramètres passés à la ressource | ?search=hello |
| Ancre | Section spécifique de la page (traité côté client) | #section |
Une méthode HTTP indique l'action que le client veut effectuer sur le serveur. C'est le verbe de la requête.
Récupère des données depuis le serveur. Pas de body dans la requête. Les paramètres sont passés dans l'URL via le query string.
GET /search?q=tryhackme HTTP/1.1
Host: google.com
Utilisé pour : charger des pages, récupérer des données. Ne doit jamais modifier l'état du serveur.
Envoie des données au serveur pour créer ou traiter une ressource. Les données sont dans le body de la requête, pas dans l'URL.
POST /login HTTP/1.1
Host: tryhackme.com
Content-Type: application/x-www-form-urlencoded
username=admin&password=secret
Utilisé pour : soumettre des formulaires, créer des ressources, envoyer des données sensibles (les données ne sont pas dans l'URL).
Met à jour une ressource existante sur le serveur en la remplaçant entièrement par le contenu envoyé.
Met à jour partiellement une ressource existante. Contrairement à PUT qui remplace tout, PATCH ne modifie que les champs envoyés.
Supprime une ressource sur le serveur.
Identique à GET mais le serveur renvoie uniquement les headers, sans le body. Utile pour vérifier si une ressource existe et obtenir ses métadonnées sans télécharger tout le contenu.
Demande au serveur quelles méthodes HTTP sont autorisées sur une ressource. Utilisé dans les mécanismes CORS (Cross-Origin Resource Sharing).
| Méthode | Action | Body ? | Idempotent |
|---|---|---|---|
| GET | Lire | Non | Oui |
| POST | Créer / Traiter | Oui | Non |
| PUT | Remplacer | Oui | Oui |
| PATCH | Modifier partiellement | Oui | Non |
| DELETE | Supprimer | Non | Oui |
| HEAD | Lire headers seulement | Non | Oui |
| OPTIONS | Lister les méthodes | Non | Oui |
Idempotent : appeler la méthode plusieurs fois produit le même résultat qu'une seule fois. GET, PUT, DELETE sont idempotents. POST ne l'est pas : soumettre deux fois le même formulaire crée deux ressources.
Le serveur répond à chaque requête avec un code de statut à 3 chiffres qui indique le résultat de la requête. Ils sont regroupés en 5 familles.
La requête est reçue, traitement en cours. Rarement vu en pratique normale.
| Code | Signification |
|---|---|
| 100 | Continue |
La requête a été reçue, comprise et acceptée avec succès.
| Code | Signification | Usage |
|---|---|---|
| 200 | OK | Succès standard pour GET |
| 201 | Created | Ressource créée avec succès (souvent après POST) |
| 204 | No Content | Succès mais pas de contenu à renvoyer |
Le client doit effectuer une action supplémentaire pour compléter la requête.
| Code | Signification | Usage |
|---|---|---|
| 301 | Moved Permanently | Redirection permanente vers une nouvelle URL |
| 302 | Found | Redirection temporaire |
| 304 | Not Modified | La version en cache est à jour, pas besoin de retélécharger |
La requête contient une erreur côté client.
| Code | Signification | Usage |
|---|---|---|
| 400 | Bad Request | Requête malformée |
| 401 | Unauthorized | Authentification requise |
| 403 | Forbidden | Authentifié mais pas autorisé |
| 404 | Not Found | Ressource introuvable |
| 405 | Method Not Allowed | Méthode HTTP non autorisée sur cette ressource |
| 429 | Too Many Requests | Rate limiting déclenché |
401 vs 403 : distinction importante 401 : tu n'es pas authentifié. Connecte-toi d'abord. 403 : tu es authentifié mais tu n'as pas le droit d'accéder à cette ressource.
Le serveur a rencontré une erreur en traitant une requête valide.
| Code | Signification | Usage |
|---|---|---|
| 500 | Internal Server Error | Erreur générique côté serveur |
| 502 | Bad Gateway | Le serveur intermédiaire a reçu une réponse invalide |
| 503 | Service Unavailable | Serveur surchargé ou en maintenance |
Les headers sont des métadonnées échangées entre le client et le serveur dans chaque requête et réponse. Ils transportent des informations de contexte, de configuration et de sécurité.
| Header | Description | Exemple |
|---|---|---|
| Host | Domaine cible (obligatoire en HTTP/1.1) | Host: tryhackme.com |
| User-Agent | Identifie le navigateur et l'OS du client | User-Agent: Mozilla/5.0 (Windows NT 10.0) |
| Accept | Types de contenu acceptés par le client | Accept: text/html, application/json |
| Accept-Language | Langues préférées du client | Accept-Language: fr-FR, en-US |
| Accept-Encoding | Algorithmes de compression acceptés | Accept-Encoding: gzip, deflate, br |
| Authorization | Credentials pour l'authentification | Authorization: Bearer eyJhbGci... |
| Cookie | Cookies stockés pour ce domaine | Cookie: session=abc123 |
| Content-Type | Type du contenu envoyé dans le body | Content-Type: application/json |
| Content-Length | Taille du body en octets | Content-Length: 348 |
| Referer | URL de la page précédente | Referer: https://google.com |
| Header | Description | Exemple |
|---|---|---|
| Content-Type | Type du contenu renvoyé | Content-Type: text/html; charset=utf-8 |
| Content-Length | Taille du contenu renvoyé | Content-Length: 1024 |
| Set-Cookie | Définit un cookie sur le client | Set-Cookie: session=abc123; HttpOnly |
| Cache-Control | Instructions de mise en cache | Cache-Control: max-age=3600 |
| Location | URL de redirection (3xx) | Location: https://tryhackme.com/login |
| Server | Logiciel du serveur (souvent masqué en prod) | Server: nginx |
| X-Frame-Options | Protège contre le clickjacking | X-Frame-Options: DENY |
| Strict-Transport-Security | Force HTTPS | Strict-Transport-Security: max-age=31536000 |
| Content-Security-Policy | Contrôle les sources de contenu autorisées | Content-Security-Policy: default-src 'self' |
Un cookie est un petit morceau de données que le serveur envoie au
navigateur via le header Set-Cookie. Le navigateur le stocke et le
renvoie automatiquement dans chaque requête suivante vers ce domaine
via le header Cookie.
HTTP est un protocole sans état (stateless). Chaque requête est indépendante et le serveur n'a aucune mémoire des requêtes précédentes. Sans cookies, tu serais déconnecté à chaque clic. Les cookies permettent au serveur de te reconnaître d'une requête à l'autre.
- Gestion de session : stocker un identifiant de session après la connexion
- Préférences utilisateur : langue, thème, paramètres
- Tracking : suivi du comportement de navigation
| Attribut | Rôle |
|---|---|
| HttpOnly | Interdit l'accès au cookie via JavaScript. Protège contre le vol de session via XSS |
| Secure | Le cookie n'est envoyé que sur des connexions HTTPS |
| SameSite | Contrôle quand le cookie est envoyé sur des requêtes cross-site. Protège contre les attaques CSRF |
| Expires / Max-Age | Durée de vie du cookie. Sans cette valeur, le cookie est de session et expire à la fermeture du navigateur |
| Domain | Domaine(s) pour lesquels le cookie est valide |
| Path | Chemin spécifique pour lequel le cookie est valide |
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Max-Age=3600
Un cookie sans HttpOnly peut être volé via XSS. Un cookie sans Secure peut être intercepté sur une connexion HTTP. Un cookie sans SameSite est vulnérable aux attaques CSRF.
POST /login HTTP/1.1
Host: tryhackme.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
Cookie: preferences=dark-mode
username=admin&password=password123
Structure :
- Ligne 1 : méthode + chemin + version HTTP
- Lignes suivantes : headers
- Ligne vide : séparateur entre headers et body
- Dernière partie : body (si présent)
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 30 Mar 2026 10:00:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1024
Set-Cookie: session=xyz789; HttpOnly; Secure; SameSite=Strict
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000
<!DOCTYPE html>
<html>
<body>Welcome back, admin</body>
</html>
Structure :
- Ligne 1 : version HTTP + code de statut + message
- Lignes suivantes : headers de réponse
- Ligne vide : séparateur
- Dernière partie : body (le contenu HTML, JSON, etc.)
Un serveur bien configuré envoie des headers qui protègent les utilisateurs contre des attaques côté client.
Strict-Transport-Security (HSTS) Force le navigateur à utiliser uniquement HTTPS pour ce domaine. Protège contre les attaques SSL stripping.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy (CSP) Définit les sources depuis lesquelles le navigateur peut charger des ressources (scripts, images, styles). Réduit drastiquement la surface d'attaque XSS.
Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com
X-Frame-Options Empêche la page d'être chargée dans une iframe. Protège contre le clickjacking.
X-Frame-Options: DENY
X-Content-Type-Options Empêche le navigateur de deviner le type MIME d'une réponse. Protège contre les attaques MIME sniffing.
X-Content-Type-Options: nosniff
Injection via paramètres GET/POST Les paramètres passés dans l'URL ou le body sont des vecteurs d'injection. SQL Injection, XSS, Command Injection passent tous par des paramètres HTTP mal validés.
Vol de session via cookies Si un cookie de session n'a pas l'attribut HttpOnly, un script JavaScript malveillant peut le lire et l'envoyer à un attaquant. L'attaquant réutilise le cookie pour usurper la session.
CSRF (Cross-Site Request Forgery) Un utilisateur authentifié visite un site malveillant. Ce site déclenche en arrière-plan une requête vers le site légitime en utilisant les cookies de session du navigateur. Le serveur croit que la requête vient de l'utilisateur. Protection : attribut SameSite sur les cookies et tokens CSRF.
Exposition d'informations via headers
Un header Server: Apache/2.4.49 révèle la version exacte du serveur
et permet à un attaquant de cibler des CVEs spécifiques.
Bonne pratique : masquer ou généraliser ces informations en production.
HTTP est le protocole de toutes les applications web. La quasi-totalité des incidents impliquant des applications web passent par HTTP. Comprendre HTTP permet de lire des logs d'accès, d'interpréter des rapports de pentest, et d'évaluer si les contrôles applicatifs d'une organisation sont réellement en place.
| Risque | Attaque | Contrôle ISO 27001 |
|---|---|---|
| Cookies sans HttpOnly/Secure | Vol de session via XSS | A.8.23 Filtrage web |
| Headers de sécurité absents | XSS, clickjacking, MIME sniffing | A.8.20 Sécurité réseau |
| HTTP sans HTTPS | Interception du trafic en clair | A.8.24 Cryptographie |
| Paramètres non validés | Injection SQL, XSS, Command Injection | A.8.19 Sécurité applicative |
| Headers serveur exposés | Reconnaissance facilitée des versions | A.8.8 Gestion des vulnérabilités |
| CSRF non protégé | Actions non autorisées au nom de l'utilisateur | A.8.19 Sécurité applicative |
| Rate limiting absent | Brute force sur les endpoints d'authentification | A.8.5 Authentification |
Questions à poser lors d'un audit applicatif :
- Le site force-t-il HTTPS avec HSTS ?
- Les cookies de session ont-ils HttpOnly, Secure et SameSite ?
- Une Content-Security-Policy est-elle définie et restrictive ?
- Les headers serveur révèlent-ils des informations de version ?
- Les entrées utilisateur sont-elles validées côté serveur ?
- Y a-t-il un mécanisme de rate limiting sur les endpoints sensibles ?
- Les codes d'erreur 500 révèlent-ils des stack traces en production ?