Chapitre 12 : Introduction au Web & Protocole HTTP

Web Pentest

Les Fondations Avant l'Exploitation Web

Premier chapitre de la partie Web Application Penetration Testing : comprendre l'architecture d'une application web, le protocole HTTP/S en détail, et les techniques de cartographie avant toute exploitation.

1. Sécurité des Apps Web

Enjeux, bonnes pratiques, et distinction entre test de sécurité et pentest.

2. Architecture & Technologies

Client-serveur, technologies front/back-end, formats d'échange de données.

3. HTTP/S & Cartographie

Anatomie des requêtes/réponses, HTTPS, crawling et spidering.

Qu'est-ce qu'une Application Web ?

Concepts

Définition

Programme accessible via un navigateur, hébergé sur un serveur web, offrant des fonctionnalités interactives et dynamiques.
Exemples : réseaux sociaux, services de messagerie, sites e-commerce, outils collaboratifs cloud.

Comment ça Fonctionne

Client-serveur : la logique et les données sont hébergées côté serveur, l'utilisateur y accède via son navigateur.
Interface : combinaison de HTML/CSS/JS pour une expérience dynamique.
Sans état (stateless) : HTTP ne conserve pas le contexte entre deux requêtes — l'application doit gérer elle-même les sessions.

Sécurité des Applications Web — Enjeux

Web Security

Pourquoi c'est Critique

Données sensibles : informations personnelles, financières, identifiants — leur exposition a un impact direct sur la confidentialité.
Confiance utilisateur : un incident érode la confiance, avec un impact réputationnel durable.
Conformité : de nombreux secteurs imposent des exigences strictes (GDPR, HIPAA, PCI DSS).
Continuité d'activité : une application indisponible ou défigurée impacte directement l'activité de l'organisation.

Bonnes Pratiques de Sécurité Web

Bonnes Pratiques

Ce qu'un Pentester Doit Vérifier

Authentification & autorisation : vérification d'identité et contrôle d'accès par rôle.
Validation des entrées : prévenir les injections (SQLi, XSS) à la source.
Communication sécurisée : HTTPS (TLS/SSL) pour protéger les données en transit.
Principe du moindre privilège et mises à jour de sécurité régulières.
WAF (Web Application Firewall) : filtre et bloque le trafic malveillant connu.
Gestion de session sécurisée : prévenir le détournement de session.

Test de Sécurité Web vs Pentest Web

Testing vs Pentest

Types de Tests de Sécurité Web

Scan de vulnérabilités automatisé (SQLi, XSS, configurations, versions obsolètes).
Revue de code et analyse statique.
Test d'authentification/autorisation, de gestion de session, et de sécurité des API.

Différences Clés

Périmètre : le testing couvre analyse statique + dynamique, le pentest se concentre sur l'exploitation active.
Objectif : identifier des faiblesses (testing) vs valider leur exploitabilité réelle (pentest).
Exploitation : absente en testing pur, centrale en pentest — mais toujours de façon contrôlée et autorisée.

Menace vs Risque

Threat vs Risk

Menace (Threat)

Toute source potentielle de dommage pouvant exploiter une vulnérabilité.
Peut être humaine (cybercriminel, insider malveillant) ou naturelle (incident, panne).

Risque (Risk)

Combinaison de la probabilité qu'une menace se concrétise et de l'impact résultant.
Une menace peut exister sans représenter un risque significatif si des mesures de protection efficaces sont en place.

Architecture d'une Application Web

Architecture

Modèle Client-Serveur

Client : interface utilisateur, affichage des pages, envoi des requêtes.
Serveur : traite les requêtes, exécute la logique métier, communique avec la base de données, génère les réponses.

Traitement Client vs Serveur

Côté client : JavaScript, validations immédiates — mais facilement manipulable par un utilisateur ou un attaquant.
Côté serveur : PHP, Python, Java... traitement des données sensibles — plus sûr, car exécuté sur un serveur de confiance.

Technologies Web — Client & Serveur

Technologies

Technologies Côté Client

HTML : structure du contenu.
CSS : présentation et style.
JavaScript : interactivité, validations locales.
Cookies & Local Storage : stockage local, gestion de session.

Technologies Côté Serveur

Serveur web : Apache2, Nginx, Microsoft IIS.
Serveur d'application : exécute la logique métier.
Base de données : MySQL, PostgreSQL, MSSQL, Oracle.
Langages serveur : PHP, Python, Java, Ruby.

Échange de Données — API, JSON, XML, REST, SOAP

Data Interchange

Formats & Protocoles Courants

API : permet à différents systèmes logiciels d'interagir et d'échanger des données.
JSON : format léger, basé sur la syntaxe JavaScript, très utilisé entre serveur et application.
XML : format structuré par balises, utilisé pour la configuration et l'échange de données complexes.
REST : style architectural utilisant les méthodes HTTP standards (GET, POST, PUT, DELETE) pour les API web.
SOAP : protocole basé sur XML pour l'échange d'informations structurées entre systèmes.

Le Protocole HTTP — Fondamentaux

HTTP

Concepts

Protocole de couche application, sans état (stateless), fonctionnant au-dessus de TCP.
Conçu pour la communication entre navigateurs (clients) et serveurs web.
Les ressources sont identifiées de façon unique par une URL/URI.
HTTP 1.1 (la version la plus utilisée) permet de réutiliser une même connexion pour plusieurs requêtes, contrairement à HTTP 1.0.

Anatomie d'une Requête HTTP

HTTP Request

Ligne de Requête

Méthode : GET, POST, PUT, DELETE — indique le type d'opération souhaitée.
URL : adresse de la ressource demandée (toujours relative à la racine "/").
Version HTTP : ex. HTTP/1.1.

En-têtes Courants

Host : permet d'héberger plusieurs sites sur une même IP.
User-Agent : identifie le navigateur, sa version, l'OS.
Accept / Accept-Encoding : types de contenu et compressions acceptés.
Authorization / Cookie : identifiants et données de session.
Connection: keep-alive permet de réutiliser la connexion (HTTP 1.1).

Anatomie d'une Réponse HTTP

HTTP Response

Structure de la Réponse

Status-Line : version HTTP + code de statut (ex: 200) + libellé (OK).
En-têtes : Content-Type, Content-Length, Set-Cookie, Cache-Control, Server (bannière du serveur web).
Corps : contenu réel de la réponse (ex: le HTML de la page).

Labo Pratique de Base

# Voir les en-têtes de la réponse
curl -v URL
curl -I -v URL

# Vérifier les méthodes HTTP autorisées
curl -v -X OPTIONS URL

# Brute-force de répertoires
dirb URL

HTTPS — HTTP Sécurisé

HTTPS

Concepts

HTTP transmet les données en clair, facilement interceptables — HTTPS ajoute une couche de chiffrement via SSL/TLS.
Garantit confidentialité, intégrité et authentification entre navigateur et serveur.

Ce que HTTPS ne Protège Pas

HTTPS ne protège pas contre les failles applicatives elles-mêmes.
Les attaques comme XSS et l'injection SQL fonctionnent toujours, peu importe si le transport est chiffré — le chiffrement protège le tuyau, pas le contenu de l'application.

Crawling & Spidering — Cartographier une Application

Crawling / Spidering

Crawling (Passif)

Navigation dans l'application en suivant les liens et formulaires accessibles publiquement, pour cataloguer sa structure.
Généralement passif — le crawler passif de Burp Suite cartographie ce qui est visité manuellement.

Spidering (Actif)

Découverte automatique de nouvelles ressources (URLs), à partir d'une liste de départ ("seeds").
Processus récursif souvent plus "bruyant" — considéré comme une technique de collecte active. Le spider d'OWASP ZAP automatise cette démarche.

Démo — Burp Suite & OWASP ZAP

Démo

Crawling avec Burp Suite

Laisser l'interception du proxy désactivée.
Naviguer manuellement sur le site pour construire progressivement la site map.

Spidering avec OWASP ZAP

Configurer FoxyProxy sur le port 8080 pour rediriger le trafic vers ZAP.
Menu Tools > Spider, sélectionner le scope, puis lancer le scan.
Les points verts indiquent les ressources liées au scope, les points rouges celles hors périmètre.

Objectifs & Modèle Mental Web

Méthodologie

Objectif : avant de chercher une vulnérabilité, comprendre comment la requête traverse le navigateur, le proxy, le serveur web, l'application et les composants internes.

1. Identifier

Surface, domaine, sous-domaines, technologies, endpoints.

→

2. Comprendre

Flux HTTP, authentification, session, API, rôles et données.

→

3. Cartographier

Pages, paramètres, méthodes, fichiers, erreurs et fonctionnalités.

→

4. Tester

Hypothèses contrôlées puis validation de l'impact.

Réflexe : une URL seule ne représente pas toute la surface d'attaque. Une application est un ensemble de routes, paramètres, rôles, états et composants.

Cycle de Vie d'une Requête Web

Méthodologie

Navigateur

Construit l'URL et les en-têtes, ajoute cookies et données utilisateur.

→

TLS / TCP

Établit le transport puis, en HTTPS, protège le canal par TLS.

→

Reverse Proxy

Nginx, Apache, CDN ou load balancer peut router et filtrer.

→

Application

Authentification, logique métier, accès aux données.

Pourquoi c'est utile ? Une anomalie peut venir de n'importe quelle couche. L'observation de la requête et de la réponse permet de localiser le comportement.

URL, URI, Origin et Host

HTTP

Décomposer une URL

https://app.example.com:443/api/users?id=42#profile

scheme : https
host : app.example.com
port : 443
path : /api/users
query : id=42
fragment : #profile, généralement traité côté navigateur

Intérêt pour le pentest

Chaque composant peut influencer le routage ou le traitement.
Les paramètres de query/path/body sont des entrées à inventorier.
Le Host est important pour le virtual hosting.

Méthodes HTTP — Sémantique et Tests

HTTP

Méthode	Usage courant	Point d'attention
GET	Lire une ressource	Paramètres dans URL, cache, exposition involontaire.
POST	Créer / déclencher une action	Body, CSRF, validation serveur.
PUT	Remplacer une ressource	Contrôle d'autorisation et modification d'objets.
PATCH	Modifier partiellement	Champs modifiables et logique métier.
DELETE	Supprimer	Autorisation et protections contre actions non voulues.
OPTIONS	Décrire les capacités HTTP	Ne constitue pas à lui seul une preuve de vulnérabilité.

À retenir : la méthode indique l'intention, mais la sécurité dépend surtout de la validation serveur et de l'autorisation appliquée à l'action.

Codes HTTP — Lire le Comportement

HTTP

2xx

Succès. 200 OK, 201 création, 204 sans contenu.

3xx

Redirection. 301/302 redirection, 304 ressource non modifiée.

4xx

Erreur côté requête. 400 syntaxe, 401 authentification, 403 accès refusé, 404 non trouvé.

5xx

Erreur côté serveur. 500 erreur interne, 502/503 problèmes de service/proxy.

Comparer

Un changement 200→403 ou 404→200 après modification d'un paramètre peut révéler une logique intéressante.

Attention

Un code HTTP ne suffit jamais à conclure. Lire aussi taille, contenu, headers et comportement métier.

Headers HTTP — Ceux à Observer

HTTP

Requête

Host : virtual hosting
Cookie : contexte de session
Authorization : mécanisme d'authentification
Content-Type : format du body
Origin / Referer : contexte de provenance
User-Agent : identification du client

Réponse

Set-Cookie : création/mise à jour de cookie
Location : redirection
Content-Type : type de contenu
Cache-Control : comportement du cache
Server : bannière éventuelle
Content-Security-Policy : politique navigateur

Point pentest : une bannière ou un header inhabituel est une piste d'énumération, pas automatiquement une vulnérabilité.

Cookies & Gestion de Session

Sessions

Attributs importants

Secure : cookie envoyé via HTTPS.
HttpOnly : limite l'accès depuis JavaScript.
SameSite : contrôle certains envois cross-site.
Domain / Path : portée du cookie.
Expiration : durée de validité.

Questions à poser

Le cookie identifie-t-il une session ?
Change-t-il après authentification ?
Est-il invalidé après logout ?
Les privilèges sont-ils liés au serveur plutôt qu'au contenu contrôlé par le client ?

Principe : l'état de session est géré par l'application alors que HTTP reste stateless. Le pentest cherche donc les incohérences entre identité, session et autorisation.

Authentification vs Autorisation

Contrôle d'accès

Authentification — « Qui es-tu ? »

Login / mot de passe
MFA
Certificat ou token
Gestion de session après connexion

Autorisation — « Que peux-tu faire ? »

Rôle utilisateur
Droits sur une ressource
Actions administratives
Accès horizontal entre utilisateurs

Erreur classique : être authentifié ne signifie pas être autorisé à accéder à toutes les ressources.

Content-Type & Formats de Body

HTTP / API

Form URL-encoded

user=alice&role=user

Courant dans les formulaires HTML.

JSON

{"user":"alice","role":"user"}

Très courant dans les API REST.

Multipart

multipart/form-data

Formulaires avec fichiers et champs multiples.

Réflexe : identifier le format réellement accepté par le serveur. Une validation côté client ou un champ masqué ne constitue pas un contrôle de sécurité.

API Web — Surface d'Attaque

API

Endpoint

/api/users/42

→

Méthode

GET / POST / PUT / DELETE

→

Entrées

Path, query, headers, JSON, fichiers

→

Autorisation

Utilisateur + rôle + objet

Inventorier les endpoints et méthodes réellement utilisés.
Comparer les réponses entre utilisateurs/rôles lorsque cela est autorisé.
Observer les erreurs et les différences de comportement.

REST vs SOAP — Comprendre le Trafic

API

REST

Style architectural, souvent HTTP + JSON.
Ressources et méthodes HTTP.
Très fréquent dans les applications modernes.

GET /api/orders/123
Authorization: Bearer TOKEN

SOAP

Protocole avec messages XML.
Souvent décrit par WSDL.
Peut être présent dans des environnements d'entreprise.

<soap:Envelope>
  ...
</soap:Envelope>

HTTP/1.1, HTTP/2 et HTTP/3

Protocoles

HTTP/1.1

Texte, connexions persistantes, une structure historique très répandue.

HTTP/2

Multiplexage de flux, compression des headers et transport binaire.

HTTP/3

S'appuie sur QUIC/UDP et améliore notamment la gestion des connexions et pertes.

Pentest : le protocole moderne ne change pas le besoin fondamental : comprendre les requêtes, les réponses, l'état applicatif et les contrôles de sécurité.

TLS — Ce qui se Passe avec HTTPS

HTTPS

ClientHello

Le client propose versions, suites et paramètres.

→

Certificat

Le serveur présente son identité cryptographique.

→

Négociation

Les parties établissent les clés de session.

→

HTTP chiffré

Les données applicatives transitent dans le canal TLS.

Distinction : TLS protège le transport entre les extrémités. Il ne garantit pas que l'application est correctement authentifiée, autorisée ou exempte de vulnérabilités.

Reconnaissance Web — Ce qu'il Faut Cartographier

Recon

Infrastructure

Domaines, sous-domaines, IP, ports, reverse proxy, CDN.

Technologies

Serveur web, framework, CMS, bibliothèques, headers.

Contenu

Pages, fichiers, répertoires, endpoints, paramètres.

Identité

Login, inscription, reset password, MFA, logout.

Rôles

Utilisateur, manager, admin, fonctions réservées.

Données

Objets, IDs, exports, uploads, API et formats d'échange.

Fingerprinting — Identifier la Stack

Recon

Indices passifs

Headers HTTP.
Cookies et noms de session.
Structure des URLs.
Commentaires ou fichiers publics.
Comportement des erreurs.

Outils

curl -I https://target.tld
whatweb https://target.tld
nmap -sV -p80,443 target.tld

Comparer plusieurs indices plutôt que se fier à une seule signature.

Attention : une technologie détectée n'implique pas qu'elle est vulnérable. La version et surtout le contexte d'utilisation doivent être vérifiés.

Énumération de Contenu — Méthode

Content Discovery

Seed

URL de départ + endpoints connus.

→

Crawl

Liens et formulaires accessibles.

→

Discovery

Répertoires, fichiers et endpoints probables.

→

Validation

Confirmer manuellement les résultats.

# Exemples
gobuster dir -u https://target.tld -w wordlist.txt
ffuf -u https://target.tld/FUZZ -w wordlist.txt
dirb https://target.tld

Interprétation : distinguer 200, 3xx, 401/403 et faux positifs. Une réponse uniforme pour les chemins inexistants nécessite une stratégie de filtrage.

Virtual Hosts & Host Header

Recon

Pourquoi ?

Plusieurs applications peuvent partager une même adresse IP et être distinguées par le nom demandé.

Host: app.target.tld

Test de découverte

ffuf -u http://IP/ -H "Host: FUZZ.target.tld" -w subdomains.txt

Comparer taille, code HTTP et contenu pour repérer les hôtes distincts.

À corréler : DNS, certificats TLS, réponses HTTP et virtual hosts peuvent révéler des surfaces différentes.

Robots.txt, Sitemap et Fichiers Publics

Recon

/robots.txt

Indique des chemins que certains robots devraient éviter. Ce n'est pas un mécanisme d'autorisation.

/sitemap.xml

Peut exposer des URLs indexables et aider à cartographier le contenu.

Fichiers

JS, sourcemaps, manifests ou fichiers de configuration peuvent révéler endpoints et métadonnées.

curl -s https://target.tld/robots.txt
curl -s https://target.tld/sitemap.xml

JavaScript Côté Client — Source d'Indices

Client-side

À rechercher

Routes d'API.
Noms de paramètres.
Fonctions d'administration.
URLs internes.
Messages d'erreur.
Clés publiques ou identifiants non sensibles.

Ce qui n'est pas un secret

Tout ce qui est livré au navigateur doit être considéré comme accessible à l'utilisateur. Une valeur présente dans JavaScript ne doit pas être utilisée comme secret de confiance.

Burp Suite — Workflow de Base

Proxy

Intercepter ou observer le trafic.

→

HTTP history

Conserver les requêtes/réponses.

→

Repeater

Modifier et rejouer une requête.

→

Comparer

Observer précisément les différences.

Réflexe : ne pas modifier plusieurs variables simultanément au début. Changer un élément à la fois facilite l'attribution du comportement.

Rejouer une Requête avec curl

HTTP / CLI

# Requête simple
curl -i https://target.tld/

# Avec headers
curl -i -H "Accept: application/json" https://target.tld/api/users

# POST JSON
curl -i -X POST https://target.tld/api/login   -H "Content-Type: application/json"   -d '{"username":"test","password":"test"}'

# Conserver les cookies
curl -i -c cookies.txt https://target.tld/
curl -i -b cookies.txt https://target.tld/profile

Pourquoi : reproduire une requête sans navigateur permet de comprendre précisément les variables qui influencent la réponse.

Paramètres — Path, Query, Body, Headers

Entrées

Emplacement	Exemple	Question de test
Path	/users/42	Le serveur vérifie-t-il l'accès à l'objet 42 ?
Query	?id=42	Le paramètre influence-t-il une ressource ou une requête ?
Body	JSON / form	Quels champs sont acceptés et lesquels sont réellement autorisés ?
Header	Authorization	Comment l'identité et le contexte sont-ils déterminés ?

Méthode : inventorier toutes les entrées avant de sélectionner une hypothèse de vulnérabilité.

Gestion des Erreurs — Ce qu'elles Révèlent

Recon

Indices utiles

Stack traces.
Noms de fichiers.
Routes internes.
Frameworks.
Messages de base de données.
IDs ou références internes.

Comparer

Une erreur sur une entrée invalide peut révéler davantage qu'une réponse normale. Tester sans provoquer de charge excessive et conserver la requête exacte.

CORS — Comprendre le Mécanisme

Headers / API

Principe

Le navigateur applique une politique d'origine. CORS permet au serveur d'indiquer quelles origines peuvent accéder à certaines réponses.

Origin: https://app.example

À observer

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Préflight OPTIONS
Origines réellement autorisées

Point important : une configuration CORS permissive n'est pas automatiquement exploitable. L'impact dépend notamment des données accessibles et du contexte d'authentification.

CSRF — Modèle Mental

Sessions

Victime connectée

Le navigateur possède une session valide.

→

Site tiers

Déclenche une requête vers la cible.

→

Serveur

Accepte la requête si les contrôles sont insuffisants.

Contrôles à observer

Token anti-CSRF.
SameSite.
Vérification Origin/Referer selon contexte.

Contexte

Le risque dépend notamment de l'usage des cookies et du type d'action effectuée.

Checklist de Cartographie Web

Méthodologie

1. Surface

Domaines, IP, ports, vhosts.

2. Stack

Web server, framework, CMS, API.

3. Contenu

URLs, répertoires, fichiers, JS.

4. Entrées

Query, path, body, headers, cookies.

5. Identité

Login, session, rôles, logout.

6. Flux

Requêtes critiques et logique métier.

# Exemple de séquence
curl -I https://target.tld
whatweb https://target.tld
gobuster dir -u https://target.tld -w wordlist.txt
# Puis validation manuelle avec Burp / curl

Arbre de Décision — Après la Cartographie

Méthodologie

Endpoint trouvé

Quel est son rôle ?

→

Entrées

Quels paramètres contrôlent le comportement ?

→

Auth

Quel utilisateur peut l'appeler ?

→

Autorisation

Quel objet/action est permis ?

→

Validation

Le comportement observé constitue-t-il réellement une faiblesse ?

Fin de reconnaissance : on doit pouvoir expliquer l'application suffisamment bien pour savoir où et pourquoi tester, plutôt que lancer des payloads au hasard.

Synthèse & Methodology Checklist — Chapitre 12

Récapitulatif

Checklist Pratique — Fondamentaux Web

1. Comprendre l'architecture (client-serveur, technologies front/back-end) avant de chercher une faille.
2. Maîtriser HTTP — requêtes, réponses, en-têtes — c'est le langage de base de toute application web.
3. HTTPS protège le transport, pas l'application : ne jamais confondre chiffrement et sécurité applicative.
4. Cartographier avant d'exploiter : crawling passif (Burp) puis spidering actif (ZAP) pour connaître toute la surface d'attaque.
5. Ce chapitre pose les bases — les techniques d'exploitation propres au web (injection, XSS...) seront abordées dans les chapitres suivants.