💡 Ce tutoriel est traduit par l'IA à partir de la version anglaise. Pour voir la version originale, vous pouvez cliquer ici
L'injection SQL est une technique populaire utilisée par les attaquants pour exploiter les applications web en créant des entrées malveillantes et en exécutant des instructions SQL arbitraires dans la base de données backend. Dans ce laboratoire (lab), nous allons configurer un environnement d'injection SQL en utilisant sqli-labs avec Docker, et effectuer des expériences pratiques pour comprendre les principes et les méthodes d'exploitation des vulnérabilités d'injection SQL.
Bienvenue dans notre cours introductif sur les tests de sécurité web, en particulier axé sur l'identification des vulnérabilités potentielles d'injection SQL. L'injection SQL est une faille de sécurité courante et potentiellement dévastatrice dans les applications web, mais avec les connaissances appropriées, vous pouvez apprendre à l'identifier et à la prévenir.
L'injection SQL est une technique où un attaquant insère du code SQL malveillant dans une requête de base de données d'une application web. Si l'application web ne nettoie pas correctement les entrées utilisateur, cela peut entraîner des violations de données, une perte de données ou d'autres problèmes graves.
Les applications web qui interagissent avec une base de données ont souvent des URL qui incluent des paramètres. Ces paramètres peuvent potentiellement être exploités s'ils ne sont pas correctement nettoyés. Par exemple, vous pourriez voir une URL qui ressemble à ceci :
http://some-website.com/page.php?id=XXDans cette URL, id est un paramètre qui interagit avec la base de données. Toute page web qui utilise de tels paramètres pourrait potentiellement être vulnérable à l'injection SQL si l'entrée n'est pas correctement nettoyée.
Une façon simple de tester les vulnérabilités d'injection SQL est d'utiliser la technique de la quote simple. Voici comment faire :
') à la valeur du paramètre dans l'URL. Par exemple, vous pourriez modifier l'URL pour qu'elle ressemble à ceci : http://some-website.com/page.php?id=1'La raison pour laquelle cela fonctionne est que les types de données numériques et de chaîne de caractères en SQL génèrent une erreur de syntaxe lorsqu'une quote simple non équilibrée est introduite. Cette erreur peut révéler la présence d'une vulnérabilité d'injection SQL.
Si aucune erreur n'est affichée lorsque vous ajoutez une quote simple, cela ne signifie pas nécessairement qu'il n'y a pas de vulnérabilité d'injection SQL. Il est possible que l'application filtre les quotes simples, ce qui vous obligerait à utiliser d'autres techniques pour tester les vulnérabilités. Ne vous inquiétez pas, nous aborderons ces techniques plus avancées dans une leçon future.
N'oubliez pas que le hacking éthique consiste à améliorer la sécurité. Respectez toujours la vie privée et la légalité dans vos tests. Bonne apprentissage!
Très bien pour avoir identifié les points potentiels d'injection SQL! Passons maintenant à l'étape suivante : déterminer le type de vulnérabilité d'injection SQL. Nous allons nous concentrer sur deux types principaux : l'injection SQL numérique et l'injection SQL basée sur des chaînes de caractères.
Lorsque le paramètre d'entrée (appelons-le x) est traité comme un entier par l'application web, la requête SQL peut ressembler à ceci :
select * from <table_name> where id = xPour identifier une injection SQL numérique, nous utilisons deux conditions logiques simples : and 1=1 et and 1=2. Voici comment procéder :
http://some-website.com/page.php?id=x and 1=1 dans votre navigateur. Si la page se charge comme prévu, passez à l'étape suivante.http://some-website.com/page.php?id=x and 1=2. Si la page renvoie une erreur ou se comporte différemment, cela peut indiquer une vulnérabilité d'injection SQL numérique.Pourquoi cela fonctionne-t-il?
Lorsque vous entrez and 1=1, la requête SQL résultante est :
select * from <table_name> where id = x and 1=1La condition 1=1 est toujours vraie, donc si la page se charge normalement, cela suggère que l'entrée est insérée directement dans la requête SQL.
Lorsque vous entrez and 1=2, la requête SQL résultante est :
select * from <table_name> where id = x and 1=2La condition 1=2 est toujours fausse, donc si la page se comporte différemment (comme en renvoyant une erreur), cela suggère que notre entrée affecte la requête SQL, indiquant une vulnérabilité potentielle d'injection SQL.
Dans certains cas, le paramètre d'entrée x est traité comme une chaîne de caractères. La requête SQL peut ressembler à ceci :
select * from <table_name> where id = 'x'Pour identifier une injection basée sur des chaînes de caractères, nous utilisons une approche similaire à celle de l'injection numérique, mais avec des conditions de chaîne : and '1'='1' et and '1'='2'. Voici comment procéder :
http://some-website.com/page.php?id=x' and '1'='1 dans votre navigateur. Si la page se charge comme prévu, passez à l'étape suivante.http://some-website.com/page.php?id=x' and '1'='2. Si la page renvoie une erreur ou se comporte différemment, cela peut indiquer une vulnérabilité d'injection SQL basée sur des chaînes de caractères.Pourquoi cela fonctionne-t-il?
Lorsque vous entrez and '1'='1', la requête SQL résultante est :
select * from <table_name> where id = 'x' and '1'='1'La condition '1'='1' est toujours vraie, donc si la page se charge normalement, cela suggère que l'entrée est insérée directement dans la requête SQL.
Lorsque vous entrez and '1'='2', la requête SQL résultante est :
select * from <table_name> where id = 'x' and '1'='2'La condition '1'='2' est toujours fausse, donc si la page se comporte différemment (comme en renvoyant une erreur), cela suggère que notre entrée affecte la requête SQL, indiquant une vulnérabilité potentielle d'injection SQL.
Dans les deux cas, rappelez-vous qu'une réponse inhabituelle de l'application web est un indice que vous avez peut-être trouvé un point d'injection SQL. Cependant, assurez-vous toujours d'avoir l'autorisation d'effectuer ces tests et utilisez vos compétences de manière responsable. Bonne apprentissage!
Dans ce laboratoire (lab), nous allons approfondir les vulnérabilités d'injection SQL. Nous nous concentrerons sur la manière d'exploiter ces vulnérabilités pour contourner l'authentification de connexion, une technique souvent appelée l'attaque du "mot de passe universel".
Pour commencer, nous devons préparer notre environnement de laboratoire. Nous allons utiliser l'application web Damn Vulnerable Web Application (DVWA) - une application web PHP/MySQL conçue pour être intentionnellement vulnérable, ce qui en fait un outil d'apprentissage idéal pour comprendre la sécurité des applications web.
Télécharger l'image Docker sqli - labs : L'image Docker sqli - labs est disponible pour téléchargement sur Docker Hub. Utilisez la commande suivante dans votre terminal pour la télécharger :
docker pull acgpiano/sqli - labsLancer le conteneur Docker sqli - labs : Après avoir téléchargé l'image, exécutez - la en utilisant la commande ci - dessous :
docker run -it -d --name sqli - labs -p 80:80 -p 13306:3306 acgpiano/sqli - labsCette commande lance un nouveau conteneur et mappe le port 80 et 3306 du conteneur aux ports 80 et 13306 de votre machine hôte, respectivement.
En suivant ces étapes, vous avez correctement configuré l'environnement de laboratoire nécessaire.
Une fois la configuration terminée, ouvrez Firefox et tapez http://localhost dans la barre d'adresse.
Si c'est la première fois que vous visitez http://localhost, cliquez sur Setup/reset Database for lab pour préparer le laboratoire, puis actualisez la page web.
Vous devriez maintenant voir une page de connexion simple lorsque vous cliquez sur Less - 11. Essayez d'entrer un nom d'utilisateur arbitraire 123 et un mot de passe 123.
La page d'erreur vous informera "Invalid username or password."
Examinons le code backend responsable du processus d'authentification :
// take the variables
if(isset($_POST['uname']) && isset($_POST['passwd']))
{
$uname=$_POST['uname'];
$passwd=$_POST['passwd'];
//logging the connection parameters to a file for analysis.
$fp=fopen('result.txt','a');
fwrite($fp,'User Name:'.$uname);
fwrite($fp,'Password:'.$passwd."\n");
fclose($fp);
// connectivity
@$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1";
$result=mysql_query($sql);
$row = mysql_fetch_array($result);
....
}La requête SQL réelle qui est exécutée est :
SELECT * FROM users WHERE username='123' AND password='123' LIMIT 0,1Cette requête est simple à comprendre : si elle retourne une ligne où le username et le password correspondent, alors la connexion est réussie.
En nous appuyant sur les connaissances acquises dans le laboratoire précédent, essayons d'entrer la charge utile (payload) suivante :
Nom d'utilisateur : 123' or 1=1 #
Mot de passe : 123' or 1=1 #
Curieusement, cela nous permet de nous connecter avec succès! La raison en est que la requête SQL réelle qui est exécutée est :
SELECT * FROM users WHERE username='123' or 1=1 #' AND password='123' or 1=1 #'En MySQL, le symbole # est utilisé pour commenter le reste de la ligne, donc la requête devient en fait :
SELECT * FROM users WHERE username='123' or 1=1Étant donné que la condition or 1=1 est toujours vraie, la requête retournera toujours un résultat, ce qui entraîne une connexion réussie.
Nous pouvons également expérimenter une variante qui n'utilise pas le symbole de commentaire :
Nom d'utilisateur : 123' or '1'='1
Mot de passe : 123' or '1'='1
La requête SQL qui est exécutée est alors :
SELECT * FROM users WHERE username='123' or '1'='1' AND password='123' or '1'='1'Dans ce cas, les deux conditions or garantissent que la condition and entre elles est toujours vraie, ce qui entraîne une connexion réussie.
Comme démontré ci - dessus, il existe de nombreuses techniques pour exploiter les vulnérabilités d'injection SQL et contourner l'authentification. N'hésitez pas à explorer et à expérimenter avec différentes charges utiles. L'objectif ici est de comprendre ces vulnérabilités afin de mieux protéger vos propres applications contre elles. Bon hacking éthique!
Dans ce laboratoire (lab), nous avons appris à identifier les vulnérabilités d'injection SQL en utilisant la technique de la quote simple et à déterminer le type d'injection SQL (numérique ou basée sur des chaînes de caractères) en utilisant des charges utiles (payloads) spécifiques. Nous avons également exploré l'exploitation des vulnérabilités d'injection SQL pour contourner l'authentification de connexion, un scénario courant connu sous le nom d'attaque du "mot de passe universel". En effectuant des expériences pratiques, nous avons acquis une expérience concrète dans la compréhension et l'exploitation des vulnérabilités d'injection SQL, qui sont courantes dans les applications web si la validation et le nettoyage des entrées utilisateur ne sont pas correctement implémentés.