Qu'est-ce que l'injection SQL (SQLi) ?
L'injection SQL (SQLi) est une vulnérabilité de sécurité Web qui permet à un attaquant d'interférer
avec les requêtes qu'une application effectue sur sa base de données.
Comment détecter les vulnérabilités d'injection SQL
Vous pouvez détecter manuellement l'injection SQL à l'aide d'un ensemble systématique de tests sur
chaque point d'entrée de l'application.
Le caractère guillemet simple 'et recherchez les erreurs ou autres anomalies.
Conditions booléennes telles que OR 1=1et OR 1=2et recherchez les différences dans les réponses
de l'application.
Injection SQL dans différentes parties de la requête
La plupart des vulnérabilités d'injection SQL se produisent dans la WHEREclause
d'une SELECTrequête. La plupart des testeurs expérimentés connaissent ce type
d’injection SQL.
Cependant, des vulnérabilités d’injection SQL peuvent survenir à n’importe quel
endroit de la requête et au sein de différents types de requêtes. Certains autres
emplacements courants où l'injection SQL se produit sont :
Dans UPDATEles instructions, dans les valeurs mises à jour ou dans
la WHEREclause.
Dans INSERTles instructions, dans les valeurs insérées.
Dans SELECTles instructions, dans le nom de la table ou de la colonne.
Dans SELECTles déclarations, dans la ORDER BYclause.
Récupération de données cachées
Imaginez une application d'achat qui affiche des produits dans différentes
catégories. Lorsque l'utilisateur clique sur la catégorie Cadeaux , son navigateur
demande l'URL :
[Link]
L'application effectue alors une requête SQL pour récupérer les détails des
produits concernés à partir de la base de données :
SELECT * FROM products WHERE category = 'Gifts' AND
released = 1
Cette requête SQL demande à la base de données de renvoyer :
tous les détails ( *)
du productstableau
où categoryestGifts
et releasedest 1.
La restriction released = 1est utilisée pour masquer les produits qui ne sont
pas commercialisés. On pourrait supposer pour les produits inédits, released
= 0.
Récupération de données cachées - Suite
L'application n'implémente aucune défense contre les attaques par injection
SQL. Cela signifie qu'un attaquant peut construire l'attaque suivante, par
exemple :
[Link]
category=Gifts'--
Cela donne la requête SQL :
SELECT * FROM products WHERE category = 'Gifts'--' AND
released = 1
Surtout, notez qu’il --s’agit d’un indicateur de commentaire en SQL. Cela signifie
que le reste de la requête est interprété comme un commentaire, ce qui le
supprime effectivement. Dans cet exemple, cela signifie que la requête n'inclut
plus AND released = 1. De ce fait, tous les produits sont affichés, y compris
ceux qui ne sont pas encore sortis.
Vous pouvez utiliser une attaque similaire pour amener l'application à afficher
tous les produits de n'importe quelle catégorie, y compris les catégories qu'elle ne
connaît pas :
[Link]
category=Gifts'+OR+1=1--
Cela donne la requête SQL :
SELECT * FROM products WHERE category = 'Gifts' OR
1=1--' AND released = 1
La requête modifiée renvoie tous les éléments pour lesquels
est categoryou Giftsest 1égal à 1. Comme 1=1c'est toujours le cas, la
requête renvoie tous les éléments.
Avertissement
Soyez prudent lorsque vous injectez la condition OR 1=1dans une requête
SQL. Même si cela semble inoffensif dans le contexte dans lequel vous injectez, il
est courant que les applications utilisent les données d'une seule requête dans
plusieurs requêtes différentes. Si votre état atteint une
instruction UPDATEou DELETE, par exemple, cela peut entraîner une perte
accidentelle de données.
Subvertir la logique des applications
Imaginez une application qui permet aux utilisateurs de se connecter avec
un nom d'utilisateur et un mot de passe. Si un utilisateur soumet le nom
d'utilisateur wieneret le mot de passe bluecheese, l'application vérifie
les informations d'identification en exécutant la requête SQL suivante :
SELECT * FROM users WHERE username = 'wiener' AND
password = 'bluecheese'
Si la requête renvoie les détails d'un utilisateur, la connexion réussit. Dans
le cas contraire, il est rejeté.
Dans ce cas, un attaquant peut se connecter sous le nom de n’importe quel
utilisateur sans avoir besoin d’un mot de passe. Ils peuvent le faire en
utilisant la séquence de commentaires SQL --pour supprimer la
vérification du mot de passe de la WHEREclause de la requête. Par
exemple, la soumission du nom d'utilisateur administrator'--et d'un
mot de passe vide entraîne la requête suivante :
SELECT * FROM users WHERE username =
'administrator'--' AND password = ''
Cette requête renvoie l'utilisateur dont usernameest administratoret
connecte avec succès l'attaquant en tant qu'utilisateur.
Lab : Vulnérabilité d'injection SQL dans la clause WHERE permettant la récupération de données
cachées
‘+OR+1=1---
Subvertir la logique des applications
Imaginez une application qui permet aux utilisateurs de se connecter avec un nom
d'utilisateur et un mot de passe. Si un utilisateur soumet le nom
d'utilisateur wieneret le mot de passe bluecheese, l'application vérifie les
informations d'identification en exécutant la requête SQL suivante :
SELECT * FROM users WHERE username = 'wiener' AND
password = 'bluecheese'
Si la requête renvoie les détails d'un utilisateur, la connexion réussit. Dans le cas
contraire, il est rejeté.
Dans ce cas, un attaquant peut se connecter sous le nom de n’importe quel
utilisateur sans avoir besoin d’un mot de passe. Ils peuvent le faire en utilisant la
séquence de commentaires SQL --pour supprimer la vérification du mot de passe
de la WHEREclause de la requête. Par exemple, la soumission du nom
d'utilisateur administrator'--et d'un mot de passe vide entraîne la requête
suivante :
SELECT * FROM users WHERE username =
'administrator'--' AND password = ''
Cette requête renvoie l'utilisateur dont usernameest administratoret
connecte avec succès l'attaquant en tant qu'utilisateur.
Atelier : Vulnérabilité d'injection SQL permettant de contourner la connexion
Attaques UNION par injection SQL
Lorsqu'une application est vulnérable à l'injection SQL et que les résultats de la
requête sont renvoyés dans les réponses de l'application, vous pouvez utiliser
le UNIONmot-clé pour récupérer des données à partir d'autres tables de la base
de données. Ceci est communément appelé attaque UNION par injection SQL.
Le UNIONmot-clé vous permet d'exécuter une ou plusieurs SELECTrequêtes
supplémentaires et d'ajouter les résultats à la requête d'origine. Par exemple:
SELECT a, b FROM table1 UNION SELECT c, d FROM table2
Cette requête SQL renvoie un seul jeu de résultats avec deux colonnes, contenant
les valeurs des colonnes aet bin table1et des colonnes cet din table2.
Attaques UNION par injection SQL - Suite
Pour qu’une UNIONrequête fonctionne, deux conditions clés doivent être
remplies :
Les requêtes individuelles doivent renvoyer le même nombre de colonnes.
Les types de données de chaque colonne doivent être compatibles entre les
requêtes individuelles.
Pour mener une attaque UNION par injection SQL, assurez-vous que votre attaque
répond à ces deux exigences. Cela implique normalement de découvrir :
Combien de colonnes sont renvoyées par la requête d'origine.
Quelles colonnes renvoyées par la requête d'origine sont d'un type de données
approprié pour contenir les résultats de la requête injectée.
Déterminer le nombre de colonnes requises
Lorsque vous effectuez une attaque UNION par injection SQL, il existe deux
méthodes efficaces pour déterminer le nombre de colonnes renvoyées par la
requête d'origine.
Une méthode consiste à injecter une série de ORDER BYclauses et à incrémenter l'index de
colonne spécifié jusqu'à ce qu'une erreur se produise.
' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3—
La deuxième méthode consiste à soumettre une série de UNION SELECTcharges utiles
spécifiant un nombre différent de valeurs nulles :
' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL—
Si le nombre de valeurs nulles ne correspond pas au nombre de colonnes, la base de données renvoie
une erreur
Lab : Attaque UNION par injection SQL, déterminant le nombre de colonnes renvoyées par la requête
Syntaxe spécifique à la base de données
Sur Oracle, chaque SELECTrequête doit utiliser le FROMmot-clé et spécifier une
table valide. Il existe une table intégrée sur Oracle appelée dualqui peut être
utilisée à cette fin. Les requêtes injectées sur Oracle devraient donc ressembler à :
' UNION SELECT NULL FROM DUAL--
Les charges utiles décrites utilisent la séquence de commentaires à double
tiret --pour commenter le reste de la requête d'origine après le point
d'injection. Sur MySQL, la séquence de doubles tirets doit être suivie d'un
espace. Alternativement, le caractère dièse #peut être utilisé pour identifier un
commentaire.
Pour plus de détails sur la syntaxe spécifique à la base de données, consultez
l' aide-mémoire pour l'injection SQL .
Rechercher des colonnes avec un type de données utile
Une attaque UNION par injection SQL vous permet de récupérer les résultats
d'une requête injectée. Les données intéressantes que vous souhaitez récupérer
se présentent normalement sous forme de chaîne. Cela signifie que vous devez
rechercher une ou plusieurs colonnes dans les résultats de la requête d'origine
dont le type de données est ou est compatible avec des données de chaîne.
Après avoir déterminé le nombre de colonnes requises, vous pouvez sonder
chaque colonne pour tester si elle peut contenir des données de chaîne. Vous
pouvez soumettre une série de UNION SELECTcharges utiles qui placent tour à
tour une valeur de chaîne dans chaque colonne. Par exemple, si la requête renvoie
quatre colonnes, vous devez soumettre :
' UNION SELECT 'a',NULL,NULL,NULL--
' UNION SELECT NULL,'a',NULL,NULL--
' UNION SELECT NULL,NULL,'a',NULL--
' UNION SELECT NULL,NULL,NULL,'a'--
Si le type de données de la colonne n'est pas compatible avec les données de
chaîne, la requête injectée provoquera une erreur de base de données
Atelier : Attaque UNION par injection SQL, recherche
d'une colonne contenant du texte
Tech gifts'UNION SELECT NULL,'qvpm3z',NULL--
Utiliser une attaque UNION par injection SQL pour récupérer des données intéressantes
Lorsque vous avez déterminé le nombre de colonnes renvoyées par la requête
d'origine et trouvé quelles colonnes peuvent contenir des données de chaîne,
vous êtes en mesure de récupérer des données intéressantes.
Supposer que:
La requête d'origine renvoie deux colonnes, qui peuvent toutes deux contenir des
données de chaîne.
Le point d'injection est une chaîne entre guillemets dans la WHEREclause.
La base de données contient une table appelée usersavec les
colonnes usernameet password.
Dans cet exemple, vous pouvez récupérer le contenu de la userstable en
soumettant l'entrée :
' UNION SELECT username, password FROM users--
Afin d'effectuer cette attaque, vous devez savoir qu'il existe une table
appelée usersavec deux colonnes appelées usernameet password. Sans ces
informations, vous devrez deviner les noms des tables et des colonnes. Toutes les
bases de données modernes offrent des moyens d'examiner la structure de la
base de données et de déterminer les tables et les colonnes qu'elles contiennent.
Atelier : Attaque UNION par injection SQL,
récupération de données à partir d'autres tables
Récupérer plusieurs valeurs dans une seule colonne
Dans certains cas, la requête de l'exemple précédent peut renvoyer
uniquement une seule colonne.
Vous pouvez récupérer plusieurs valeurs ensemble dans cette seule
colonne en concaténant les valeurs ensemble. Vous pouvez inclure un
séparateur pour vous permettre de distinguer les valeurs combinées. Par
exemple, sur Oracle, vous pouvez soumettre l'entrée :
' UNION SELECT username || '~' || password FROM
users--
Cela utilise la séquence double-pipe ||qui est un opérateur de
concaténation de chaînes sur Oracle. La requête injectée concatène les
valeurs des champs usernameet password, séparées par le ~caractère.
Les résultats de la requête contiennent tous les noms d'utilisateur et mots
de passe, par exemple :
...
administrator~s3cure
wiener~peter
carlos~montoya
...
Différentes bases de données utilisent une syntaxe différente pour effectuer
la concaténation de chaînes. Pour plus de détails, consultez l' aide-
mémoire pour l'injection SQL .
Examen de la base de données dans les attaques
par injection SQL
Pour exploiter les vulnérabilités d'injection SQL, il est souvent nécessaire
de rechercher des informations sur la base de données. Ceci comprend:
Le type et la version du logiciel de base de données.
Les tables et colonnes que contient la base de données.
Interrogation du type et de la version de la base
de données
Vous pouvez potentiellement identifier à la fois le type et la version de
la base de données en injectant des requêtes spécifiques au
fournisseur pour voir si l'une d'entre elles fonctionne.
Voici quelques requêtes permettant de déterminer la version de la
base de données pour certains types de bases de données courants :
Type de base de données Requête
Microsoft, MySQL SELECT @@version
Oracle SELECT * FROM v$version
PostgreSQL SELECT version()
Par exemple, vous pouvez utiliser une UNIONattaque avec l'entrée
suivante :
' UNION SELECT @@version--
Cela pourrait renvoyer la sortie suivante. Dans ce cas, vous pouvez
confirmer que la base de données est Microsoft SQL Server et voir la
version utilisée
Lab : Attaque par injection SQL, interrogation du
type et de la version de la base de données sur
MySQL et Microsoft
Corporate gifts'UNION SELECT @@version,NULL#
Lister le contenu de la base de données
La plupart des types de bases de données (à l'exception d'Oracle)
disposent d'un ensemble de vues appelé schéma d'information. Cela fournit
des informations sur la base de données.
Par exemple, vous pouvez effectuer une
requête information_schema.tablespour répertorier les tables de la
base de données :
SELECT * FROM information_schema.tables
Cela renvoie une sortie comme la suivante :
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE
=====================================================
MyDatabase dbo Products BASE TABLE
MyDatabase dbo Users BASE TABLE
MyDatabase dbo Feedback BASE TABLE
Cette sortie indique qu'il existe trois tables,
appelées Products, Userset Feedback.
Vous pouvez ensuite effectuer une
requête information_schema.columnspour répertorier les colonnes
dans des tables individuelles :
SELECT * FROM information_schema.columns WHERE
table_name = 'Users'
Cela renvoie une sortie comme la suivante :
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME
DATA_TYPE
======================================================
===========
MyDatabase dbo Users UserId
int
MyDatabase dbo Users Username
varchar
MyDatabase dbo Users Password
varchar
Cette sortie affiche les colonnes de la table spécifiée et le type de données
de chaque colonne
Atelier : Attaque par injection SQL, répertoriant le
contenu de la base de données sur des bases de
données non Oracle
Injection SQL aveugle
Dans cette section, nous décrivons les techniques permettant de
rechercher et d'exploiter les vulnérabilités d'injection SQL aveugle.
Qu’est-ce que l’injection SQL aveugle ?
L'injection SQL aveugle se produit lorsqu'une application est vulnérable à
l'injection SQL, mais que ses réponses HTTP ne contiennent pas les
résultats de la requête SQL appropriée ni les détails des erreurs de base de
données.
De nombreuses techniques telles que UNIONles attaques ne sont pas
efficaces face aux vulnérabilités d’injection SQL aveugle. En effet, ils
s'appuient sur la possibilité de voir les résultats de la requête injectée dans
les réponses de l'application. Il est toujours possible d'exploiter l'injection
SQL aveugle pour accéder à des données non autorisées, mais différentes
techniques doivent être utilisées.
Exploiter l'injection SQL aveugle en déclenchant des
réponses conditionnelles
Considérez une application qui utilise des cookies de suivi pour recueillir
des analyses sur l'utilisation. Les requêtes adressées à l'application
incluent un en-tête de cookie comme celui-ci :
Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4
Lorsqu'une requête contenant un TrackingIdcookie est traitée,
l'application utilise une requête SQL pour déterminer s'il s'agit d'un
utilisateur connu :
SELECT TrackingId FROM TrackedUsers WHERE TrackingId =
'u5YD3PapBcR4lN3e7Tj4'
Cette requête est vulnérable à l'injection SQL, mais les résultats de la
requête ne sont pas renvoyés à l'utilisateur. Cependant, l'application se
comporte différemment selon que la requête renvoie ou non des
données. Si vous soumettez un TrackingId, la requête renvoie des
données et vous recevez un message « Bienvenue » dans la réponse.
Ce comportement est suffisant pour pouvoir exploiter la vulnérabilité
d'injection SQL aveugle. Vous pouvez récupérer des informations en
déclenchant différentes réponses de manière conditionnelle, en fonction
d'une condition injectée.
Exploiter l'injection SQL aveugle en déclenchant des
réponses conditionnelles - Suite
Pour comprendre le fonctionnement de cet exploit, supposons que deux
requêtes soient envoyées contenant TrackingIdtour à tour les valeurs de
cookie suivantes :
…xyz' AND '1'='1
…xyz' AND '1'='2
La première de ces valeurs amène la requête à renvoyer des
résultats, car la condition injectée AND '1'='1est vraie. En
conséquence, le message « Bienvenue » s'affiche.
La deuxième valeur fait que la requête ne renvoie aucun résultat, car
la condition injectée est fausse. Le message "Bienvenue" ne s'affiche
pas.
Cela nous permet de déterminer la réponse à n’importe quelle condition
injectée et d’extraire les données une par une.
Exploiter l'injection SQL aveugle en déclenchant des
réponses conditionnelles - Suite
Par exemple, supposons qu'il existe une table appelée Usersavec les
colonnes Usernameet Passwordet un utilisateur
appelé Administrator. Vous pouvez déterminer le mot de passe de cet
utilisateur en envoyant une série d'entrées pour tester le mot de passe, un
caractère à la fois.
Pour ce faire, commencez par l'entrée suivante :
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE
Username = 'Administrator'), 1, 1) > 'm
Cela renvoie le message « Bienvenue », indiquant que la condition injectée
est vraie et que le premier caractère du mot de passe est donc supérieur
à m.
Ensuite, nous envoyons l'entrée suivante :
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE
Username = 'Administrator'), 1, 1) > 't
Cela ne renvoie pas le message « Bienvenue », indiquant que la condition
injectée est fausse et que le premier caractère du mot de passe n'est donc
pas supérieur à t.
Finalement, nous envoyons l'entrée suivante, qui renvoie le message
"Bienvenue", confirmant ainsi que le premier caractère du mot de passe
ests :
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE
Username = 'Administrator'), 1, 1) = 's
Nous pouvons poursuivre ce processus pour déterminer systématiquement
le mot de passe complet de l' Administratorutilisateur.
Note
La SUBSTRINGfonction est appelée SUBSTRsur certains types de bases de
données. Pour plus de détails, consultez l' aide-mémoire pour l'injection
SQL .
Atelier : Injection SQL aveugle avec réponses
conditionnelles
