Principes fondamentaux des vulnérabilités d'injection SQL

Beginner

💡 Ce tutoriel est traduit par l'IA à partir de la version anglaise. Pour voir la version originale, vous pouvez cliquer ici

Introduction

Bienvenue dans ce laboratoire interactif! Nous allons nous concentrer sur les vulnérabilités d'injection SQL, un risque courant et grave pour les applications web. En termes simples, les attaques d'injection SQL se produisent lorsqu'une application reçoit des données qui n'ont pas été correctement vérifiées ou encodées, et ces données sont incluses dans une requête SQL. Cette faille peut permettre aux cyberattaquants d'exécuter des commandes SQL malveillantes, ce qui peut conduire à un accès non autorisé à des données confidentielles ou leur permettre d'effectuer d'autres actions nuisibles.

L'objectif de ce laboratoire est double. Premièrement, nous visons à démystifier les concepts clés des vulnérabilités d'injection SQL en les décomposant en éléments compréhensibles. Deuxièmement, nous proposons des exercices pratiques pour vous aider à apprendre à exploiter ces vulnérabilités, non pas dans un but malveillant, mais pour mieux les comprendre et les prévenir. Cette approche pratique vous dotera des connaissances et des compétences nécessaires pour protéger vos applications contre de telles menaces.


Skills Graph

Configuration de l'environnement de laboratoire

Dans cette section, nous vous guiderons tout au long du processus de configuration d'un environnement de laboratoire où vous pourrez pratiquer les attaques d'injection SQL.

  1. Téléchargement de l'image Docker DVWA :
    L'image Docker DVWA est disponible sur Docker Hub. Vous pouvez la télécharger en utilisant la commande suivante :

    docker pull vulnerables/web-dvwa
  2. Lancement du conteneur Docker DVWA :
    Après avoir téléchargé l'image, vous pouvez la lancer avec la commande suivante :

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

    Cette commande démarrera un nouveau conteneur et mappera le port 80 du conteneur sur le port 80 de votre machine hôte.

L'étape ci-dessus prépare l'environnement nécessaire pour le laboratoire. Une fois la configuration terminée, lancez le navigateur Firefox sur votre bureau et entrez l'URL suivante : http://localhost.

Après un court instant, vous arriverez sur la page de connexion. Les identifiants par défaut sont les suivants : nom d'utilisateur - "admin" et mot de passe - "password".

Vous serez accueilli par la page web DVWA (Damn Vulnerable Web Application). Cliquez sur le bouton "Create/Reset Database" pour générer une nouvelle base de données pour l'application.

Note importante : Dans le cadre de ce laboratoire, nous allons définir le niveau de sécurité sur "low" (faible). Ce réglage rend les vulnérabilités d'injection SQL plus évidentes. Pour ce faire, sélectionnez "low" dans le menu déroulant "Security Level", puis appuyez sur le bouton "Submit".

Identifier le point d'injection SQL

Dans ce module, nous allons découvrir la présence d'une vulnérabilité d'injection SQL dans une application.

Étape 1 : Accéder à la page d'injection SQL

Dans le menu de gauche de l'application, vous trouverez un lien intitulé "SQL Injection". Cliquez sur ce lien pour accéder à la page d'injection SQL. Ici, vous verrez un formulaire demandant un identifiant d'utilisateur.

Étape 2 : Entrer un identifiant d'utilisateur exemple

Essayons d'entrer un identifiant d'utilisateur pour voir ce qui se passe.

Exemple de saisie :

1

Tapez "1" dans le formulaire et cliquez sur le bouton "Submit". La sortie devrait afficher les détails d'un utilisateur dont l'identifiant est 1.

Étape 3 : Inspecter le code source

En cliquant sur le bouton "View Source", vous pouvez inspecter le code source de la page. Vous devriez voir quelque chose qui ressemble au code PHP suivant :

$id = $_GET['id'];
$sql = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";
$result = mysqli_query($conn, $sql);

Ce code révèle que l'application construit une requête SQL en concaténant directement l'entrée de l'utilisateur avec la déclaration SQL. C'est une erreur courante qui peut potentiellement créer des vulnérabilités d'injection SQL.

Étape 4 : Confirmer la vulnérabilité d'injection SQL

Pour vérifier l'existence d'une vulnérabilité d'injection SQL, essayons d'injecter une apostrophe simple (') après la valeur "1". Entrez ce qui suit dans le formulaire :

1'

Si vous voyez un message d'erreur de base de données, cela signifie que l'application est effectivement vulnérable aux attaques d'injection SQL. C'est une étape clé pour identifier et ensuite résoudre de telles vulnérabilités.

Déterminer le type d'injection SQL et le type de base de données

Dans cette section, nous vous guiderons tout au long du processus d'identification du type de vulnérabilité d'injection SQL et du type de base de données utilisée par une application donnée.

Notre premier objectif est de déterminer le nombre de colonnes retournées par la requête SQL originale. Pour ce faire, nous allons utiliser la clause ORDER BY.

Exemple de code :

1' ORDER BY 1#
1' ORDER BY 2#
1' ORDER BY 3#

Veuillez entrer les instructions SQL ci-dessus une par une dans le formulaire. Si l'application se comporte comme prévu, les deux premières requêtes s'exécuteront sans erreur, tandis que la troisième échouera. Cette erreur indique que la requête SQL originale retourne deux colonnes.

Ensuite, nous pouvons utiliser l'opérateur UNION pour extraire des données supplémentaires de la base de données.

Exemple de code :

1' UNION SELECT version(), @@version_compile_os#

Cette instruction SQL récupérera la version de la base de données et la version du système d'exploitation sur lequel elle s'exécute.

Après avoir exécuté cette requête, la sortie devrait afficher les informations concernant la version de la base de données et le système d'exploitation.

Récupérer le nom de la base de données

Dans cette leçon, nous vous guiderons tout au long du processus de récupération du nom de la base de données utilisée par une application. C'est une compétence essentielle, surtout lorsque vous essayez de comprendre la structure et l'organisation d'une base de données.

Exemple de code :

1' UNION SELECT database(), user()#

La requête SQL ci-dessus est un exemple d'une technique appelée "injection SQL". C'est une technique d'injection de code que les attaquants utilisent pour exploiter une vulnérabilité de sécurité située au niveau de la couche base de données d'une application. Cette requête spécifique récupère le nom de la base de données actuelle et l'utilisateur exécutant la requête.

Voici ce qui se passe :

  • 1' UNION : C'est la première partie de l'injection SQL. La partie 1' sert à compléter la requête que l'application est susceptible d'exécuter. Le mot-clé UNION est utilisé pour combiner les résultats de deux ou plusieurs instructions SELECT sans retourner de lignes en double.
  • SELECT database(), user()# : Cette partie de la requête est la charge utile que vous injectez. La fonction database() récupère le nom de la base de données actuelle, et la fonction user() récupère le nom de l'utilisateur exécutant la requête.

Après avoir soumis la requête, vous devriez voir le nom de la base de données et les informations sur l'utilisateur dans la sortie. Ces informations peuvent être essentielles pour mieux comprendre la structure de la base de données et les privilèges de l'utilisateur dans le contexte de l'application.

N'oubliez pas que la compréhension de ces techniques aide non seulement à exploiter les vulnérabilités, mais aussi à créer des applications sécurisées en sachant contre quoi se protéger.

Récupérer les noms des tables

Dans cette leçon, nous allons aller plus loin dans l'exploration de la structure de la base de données en récupérant les noms des tables qu'elle contient. Comprendre la structure des tables est crucial lorsque vous essayez d'extraire ou de manipuler des données dans une base de données.

Exemple de code :

1' UNION SELECT table_name, table_schema FROM information_schema.tables WHERE table_schema = 'dvwa'#

La requête SQL ci-dessus continue d'utiliser la technique d'injection SQL. Cette fois, elle est utilisée pour récupérer les noms des tables dans la base de données et leur schéma de base de données respectif.

Voici le détail :

  • 1' UNION : Comme expliqué précédemment, cette partie sert à compléter la requête probable de l'application et à la combiner avec notre charge utile injectée.
  • SELECT table_name, table_schema FROM information_schema.tables WHERE table_schema = 'dvwa' : Cette partie de la requête est notre charge utile injectée. Elle récupère les noms des tables et leur schéma de base de données respectif à partir de la table système information_schema.tables, plus précisément pour le schéma 'dvwa'.

La table système information_schema.tables contient des informations sur toutes les tables de la base de données. Le table_schema fait référence au nom de la base de données dont la table fait partie, et table_name est le nom de la table.

Après avoir soumis la requête, vous devriez voir les noms des tables et leur schéma de base de données respectif dans la sortie. Ces informations peuvent fournir une feuille de route pour une exploration ou une exploitation plus approfondie de la base de données.

Comme toujours, n'oubliez pas que la compréhension de ces techniques est essentielle non seulement pour exploiter les vulnérabilités, mais aussi pour créer des applications sécurisées en sachant contre quoi se protéger.

Récupérer les noms de colonnes et les données

Dans cette leçon, nous allons approfondir notre connaissance de la structure de la base de données en récupérant les noms des colonnes d'une table spécifique. Grâce à ces informations, nous pourrons ensuite extraire des données potentiellement sensibles de la table.

Exemple de code :

1' UNION SELECT 1, group_concat(column_name) FROM information_schema.columns WHERE table_name = 'users'#

La requête SQL ci-dessus utilise l'injection SQL pour récupérer les noms des colonnes de la table 'users'. Elle concatène ces noms de colonnes en une seule chaîne de caractères pour faciliter la visualisation.

Voici le détail :

  • 1' UNION : Comme expliqué précédemment, cette partie sert à compléter la requête probable de l'application et à la combiner avec notre charge utile injectée.
  • SELECT 1, group_concat(column_name) FROM information_schema.columns WHERE table_name = 'users' : Cette partie de la requête est notre charge utile injectée. Elle récupère les noms des colonnes de la table 'users' et les concatène en une seule chaîne de caractères à l'aide de la fonction group_concat.

Après avoir soumis la requête, vous devriez voir les noms des colonnes dans la sortie.

Maintenant que nous avons les noms des colonnes, nous pouvons récupérer des données sensibles de la table 'users'.

Exemple de code :

1' UNION SELECT user, password FROM users#

Cette requête SQL utilise l'injection SQL pour récupérer les colonnes 'user' et 'password' de la table 'users'.

Après avoir soumis la requête, vous devriez voir les noms d'utilisateur et les mots de passe hachés dans la sortie. Ces informations peuvent être extrêmement sensibles, et comprendre comment elles peuvent être extraites est essentiel tant pour exploiter les vulnérabilités que pour vous protéger contre de telles attaques.

N'oubliez pas que le but de la compréhension de ces techniques est double : identifier les vulnérabilités potentielles et construire des applications plus sécurisées.

Résumé

Dans ce laboratoire, vous avez appris à connaître les vulnérabilités d'injection SQL et à les exploiter grâce à des exercices pratiques. Vous avez configuré une application web vulnérable, identifié le point d'injection SQL, déterminé le type d'injection SQL et le type de base de données, et récupéré des informations sensibles de la base de données en exploitant la vulnérabilité d'injection SQL.

En terminant ce laboratoire, vous avez acquis une expérience pratique dans la compréhension et l'exploitation des vulnérabilités d'injection SQL, qui figurent parmi les vulnérabilités les plus courantes et dangereuses des applications web. Cette connaissance vous aidera à identifier et à atténuer de telles vulnérabilités dans des scénarios réels, améliorant ainsi vos compétences en matière de sécurité des applications web.