Module : Sécurité des Applications Web

Niveau : 3ème année IRIC

Injections SQL
L'injection SQL (SQLi) est une vulnérabilité de sécurité courante qui permet à un attaquant
d'interférer avec les requêtes SQL faites par une application web à une base de données. En
exploitant cette faille, l'attaquant peut manipuler les requêtes SQL de manière à contourner les
mécanismes d'authentification, extraire ou modifier des données sensibles, voire parfois
compromettre entièrement l'application.
Les injections SQL surviennent généralement lorsque les entrées fournies par l'utilisateur ne
sont pas correctement validées ou filtrées, permettant à l'attaquant d'insérer des fragments de
code SQL dans les requêtes exécutées par l'application.
Il existe plusieurs types d'attaques par injection SQL, chacune exploitant un aspect spécifique
des interactions avec la base de données.
• Injection SQL basée sur une erreur :
Ce type d'injection permet à un attaquant d'extraire des informations utiles à partir des messages
d'erreur retournés par la base de données. En provoquant volontairement une erreur dans la
requête SQL, l'attaquant peut obtenir des informations sensibles telles que la structure de la
base de données, les noms des tables ou les types de données.
• Injection SQL aveugle (Blind SQL Injection) :
Dans ce cas, l'application ne retourne pas directement des messages d'erreur détaillés, rendant
l'exploitation plus difficile. Cependant, l'attaquant peut encore manipuler les requêtes SQL et
déduire les informations à partir des réponses de l'application (par exemple, si une page charge
ou non, selon si une condition SQL est vraie ou fausse).
• Injection UNION :
Cette technique utilise l'opérateur SQL UNION pour combiner le résultat de plusieurs requêtes
en une seule. Les attaquants peuvent injecter des requêtes supplémentaires pour récupérer des
informations d'autres tables de la base de données. C'est une méthode efficace pour extraire
rapidement de grandes quantités de données.
• Injection dans une sous-requête (Subquery Injection) :
L'injection SQL peut également se produire dans une sous-requête, c'est-à-dire une requête SQL
imbriquée à l'intérieur d'une autre requête. Cela permet à l'attaquant de manipuler non
seulement la requête principale, mais aussi les sous-requêtes qui alimentent les résultats.
• Injection SQL de contournement d'authentification :
Ce type d'injection est utilisé pour contourner les systèmes de connexion. En exploitant une
injection SQL dans une requête de validation d'identifiants, l'attaquant peut accéder à un compte
Module : Sécurité des Applications Web
Niveau : 3ème année IRIC

sans connaître les identifiants corrects, en modifiant par exemple une requête de type SELECT
* FROM users WHERE username = 'admin' AND password = '' OR '1'='1'.

Atelier 1 : Faille d'injection SQL dans la clause WHERE permettant la

récupération de données cachées

L'objectif principal de cet atelier est d'exploiter une injection SQL dans la clause WHERE d'une
requête pour afficher des données cachées qui ne devraient pas être visibles via l'interface
utilisateur de l'application. Pour réussir le laboratoire, il faudra manipuler la requête SQL afin
de contourner les conditions de filtrage définies par l'application.

Accédez à l’atelier

1. Analyse de la requête initiale :

o Naviguez sur l'application web vulnérable et identifiez une page ou un formulaire qui
exécute des requêtes SQL, comme un champ de recherche ou une page listant des
éléments en fonction d'un filtre.
o Utilisez des outils comme Burp Suite pour intercepter les requêtes HTTP et observer
les paramètres envoyés au serveur.

2. Tentative d'injection simple :

o Testez si l'application est vulnérable en injectant un caractère simple,

comme ' (apostrophe) dans l'entrée utilisateur. Cela pourrait provoquer une erreur
SQL, indiquant que l'entrée est directement intégrée à la requête SQL sans être
correctement échappée.
3. Modification de la requête WHERE :
o Si une erreur SQL se produit, essayez d'injecter une condition qui annule la
condition WHERE d'origine.
Recommandation de sécurité :Une telle vulnérabilité peut être évitée en utilisant des
requêtes paramétrées (prepared statements) qui traitent les entrées utilisateur comme des
paramètres, empêchant ainsi toute manipulation directe des requêtes SQL. De plus,
valider et échapper correctement toutes les données entrées par l'utilisateur est essentiel
pour éviter les injections SQL.
Module : Sécurité des Applications Web
Niveau : 3ème année IRIC

Atelier 2 : Vulnérabilité d'injection SQL permettant de contourner la

connexion

Ce laboratoire montre comment une vulnérabilité d'injection SQL peut être exploitée pour
contourner les mécanismes d'authentification. L'attaque cible une page de connexion qui utilise
une requête SQL non sécurisée pour valider les informations d'identification des utilisateurs.
En modifiant cette requête via une injection SQL, un attaquant peut se connecter sans fournir
de véritables identifiants. L'objectif est de contourner la page de connexion en utilisant une
injection SQL pour accéder à un compte utilisateur sans connaître son mot de passe.

Accédez à l’atelier

1. Accéder à la page de connexion :

o Rendez-vous sur la page de connexion de l'application. Typiquement, cette page

demandera un nom d'utilisateur et un mot de passe, puis enverra ces informations au
serveur pour validation via une requête SQL.
2. Injection SQL dans le champ de connexion :
o La page de connexion est souvent vulnérable lorsque les informations saisies par
l'utilisateur sont directement intégrées à une requête SQL
o Pour tester la vulnérabilité, entrez une chaîne de caractères malveillante dans le champ
du nom d'utilisateur ou du mot de passe
3. Comprendre la logique de contournement :
o La chaîne injectée modifie la requête SQL
o L'expression '1'='1' est toujours vraie, ce qui signifie que la requête renverra le premier
utilisateur trouvé dans la base de données, contournant ainsi la vérification des
identifiants.
4. Valider l'accès non autorisé :
o Si l'application est vulnérable, cette requête modifiée permettra de contourner
l'authentification et de vous connecter sans avoir besoin d'un nom d'utilisateur et d'un
mot de passe valides.
Module : Sécurité des Applications Web
Niveau : 3ème année IRIC

Recommandation de sécurité :Pour éviter ce type d'attaque, les développeurs doivent

utiliser des requêtes préparées (requêtes paramétrées) ou des ORM (Object-Relational
Mapping) qui traitent les entrées utilisateur comme des paramètres, empêchant l'injection
directe dans les requêtes SQL. Il est également essentiel de valider et d'échapper toutes
les entrées utilisateur dans les formulaires d'authentification.

Atelier 3 : Attaque SQL Injection UNION – Détermination du nombre de

colonnes retournées par la requête

Ce laboratoire vous montre comment exploiter une injection SQL en utilisant

l'opérateur UNION. L'attaque UNION permet à un attaquant de combiner les résultats de
plusieurs requêtes SQL dans une seule réponse. Avant de pouvoir extraire des données
supplémentaires, l'attaquant doit déterminer le nombre exact de colonnes dans la requête SQL
d'origine. L'objectif est d'utiliser une injection SQL pour déterminer combien de colonnes sont
retournées par la requête exécutée par l'application. Cette information est nécessaire pour
réussir une attaque UNION.

Accédez à l’atelier

1. Identifier une entrée vulnérable :

o Cherchez un champ de saisie utilisateur, comme un champ de recherche ou un

paramètre dans l'URL, qui envoie une requête SQL. Utilisez Burp Suite pour
intercepter la requête si nécessaire.
2. Injection SQL initiale :
o Testez si la requête est vulnérable à une injection SQL en essayant une simple injection
comme ' OR 1=1--. Si cela modifie les résultats retournés, alors l'application est
vulnérable.
3. Tentative d'injection avec l'opérateur UNION :
o L'étape suivante consiste à tester l'injection UNION pour déterminer le nombre de
colonnes que la requête originale retourne. Cela se fait généralement en essayant
différentes combinaisons d'injections SQL avec le mot-clé UNION SELECT. Si une
erreur est retournée, cela signifie que le nombre de colonnes n'est pas correct.
o Essayez avec des combinaisons comme NULL, NULL, NULL-- jusqu'à ce que la
requête soit acceptée sans erreur.
Module : Sécurité des Applications Web
Niveau : 3ème année IRIC

o Lorsque vous atteignez le nombre correct de colonnes, la requête réussira et ne

générera plus d'erreur. Vous aurez alors déterminé combien de colonnes sont
retournées par la requête originale.
Recommandation de sécurité :Les attaques UNION peuvent être évitées en utilisant des
requêtes préparées (paramétrées), qui empêchent l'injection de code malveillant dans les
requêtes SQL. De plus, il est crucial de limiter les informations que l'application renvoie
en cas d'erreur et de valider toutes les entrées utilisateurs.

Atelier 4 : Attaque SQL Injection UNION – Trouver une colonne contenant

du texte

Ce laboratoire explore une vulnérabilité d'injection SQL où l'attaquant utilise

l'opérateur UNION pour identifier une colonne dans la base de données qui peut contenir et
afficher des données textuelles. Une fois cette colonne identifiée, l'attaquant peut exploiter cette
colonne pour afficher des informations sensibles. L'objectif est d'utiliser une injection SQL
UNION pour trouver une colonne dans la requête qui accepte et affiche du texte, afin de pouvoir
injecter et visualiser des données.

Accédez à l’atelier

2. Injection initiale :
o Commencez par vérifier si l'application est vulnérable à une injection SQL, comme
dans les laboratoires précédents
3. Déterminer le nombre de colonnes (si ce n'est pas déjà fait) :
o Si vous n'avez pas encore déterminé le nombre de colonnes retournées par la requête
SQL, suivez les étapes du lab précédent pour injecter les requêtes nécessaires
4. Injection UNION avec des colonnes textuelles :
o Maintenant que vous connaissez le nombre de colonnes, le but est de trouver une
colonne capable de contenir des données textuelles.
o Si la chaîne de caractères apparaît dans la réponse, cela signifie que la première
colonne accepte et affiche des données textuelles.
5. Tester toutes les colonnes :
o Si la chaine ne s'affiche pas, cela signifie que la première colonne ne contient pas de
texte. Essayez alors la même injection avec la deuxième ou la troisième colonne,
Module : Sécurité des Applications Web
Niveau : 3ème année IRIC

o Continuez à tester jusqu'à ce que vous trouviez une colonne qui accepte et affiche du
texte dans la réponse.
Recommandation de sécurité :Pour éviter ces attaques, il est crucial d'utiliser des requêtes
SQL préparées ou paramétrées, qui empêchent l'injection directe dans les requêtes. De
plus, toute entrée utilisateur doit être soigneusement validée et échappée pour s'assurer
qu'aucun contenu malveillant ne puisse être injecté dans une requête SQL.

Atelier 5: attaque UNION par injection SQL, récupération de données à

partir d'autres tables

Ce laboratoire vous montre comment exploiter une injection SQL en utilisant

l'opérateur UNION pour récupérer des données provenant d'autres tables de la base de données.
Une fois qu'un attaquant a déterminé le nombre de colonnes et identifié les colonnes contenant
du texte, il peut étendre l'attaque en récupérant des informations sensibles stockées dans d'autres
tables. L'objectif est d'utiliser une injection SQL UNION pour accéder et extraire des données
sensibles à partir d'autres tables présentes dans la base de données, telles que des informations
d'utilisateurs ou des données confidentielles qui ne sont normalement pas exposées à
l'utilisateur.

Accédez à l’atelier

1. Validation de la vulnérabilité initiale :

o Comme pour les précédents laboratoires, commencez par identifier une entrée
vulnérable qui pourrait permettre une injection SQL. Utilisez un champ de saisie
ou un paramètre dans l'URL pour tester si l'application est vulnérable à une
injection.
2. Détermination du nombre de colonnes et identification des colonnes textuelles :
o Si ce n'est pas encore fait, déterminez le nombre de colonnes retournées par la
requête SQL en utilisant une attaque UNION. Ensuite, identifiez quelles
colonnes acceptent et affichent des données textuelles.
3. Identification des tables disponibles :
o Une fois que vous avez trouvé une colonne textuelle, l'étape suivante consiste à
essayer de récupérer les noms des tables et des colonnes disponibles dans la base
Module : Sécurité des Applications Web
Niveau : 3ème année IRIC

de données. Cela peut souvent se faire en manipulant l'attaque SQL UNION pour
révéler la structure de la base de données.
4. Accès aux données d'autres tables :
o Après avoir identifié les noms des tables, vous pouvez modifier l'injection SQL
pour récupérer des informations spécifiques à partir d'autres tables, comme les
données des utilisateurs, les adresses email, ou d'autres informations
confidentielles.
5. Affichage des données sensibles :
o L'attaque UNION vous permet d'extraire des données de plusieurs tables
simultanément, et d'afficher ces informations dans les colonnes textuelles que
vous avez identifiées.

Recommandation de sécurité : Pour prévenir ce type d'attaque, les développeurs doivent

implémenter des requêtes préparées ou paramétrées qui isolent les entrées utilisateur du
code SQL exécuté. En outre, restreindre les privilèges d'accès à la base de données et
éviter d'exposer des informations sensibles par défaut sont des pratiques importantes
pour renforcer la sécurité.

Atelier 6: attaque UNION par injection SQL, récupération de plusieurs

valeurs dans une seule colonne