compte rendu SQL
INJECTION
PARTIE1 :
Les deux adresses IP observées dans les paquets capturés (10.0.2.4 et 10.0.2.15) représentent
respectivement l’attaquant et le serveur cible.
PARTIE2 :
L’attaquant teste si le champ UserID est vulnérable aux injections SQL en entrant une condition
toujours vraie (1=1). La réponse du serveur prouve la vulnérabilité.
Capture liée : Ligne 13 avec Follow HTTP Stream.
PARTIE3 :
L’attaquant utilise une commande SQL avancée pour récupérer le nom de la
base de données (dvwa) et l’utilisateur (root@localhost).
PARTIE4 :
L’attaquant utilise version() pour obtenir des infos système : cela peut lui indiquer les failles
potentielles exploitables selon la version.
MySQL 5.7.12-0
l’attaquant d’afficher les noms des colonnes de la table "users", ce qui l’aide à
comprendre comment accéder aux identifiants et mots de passe.
L’attaquant affiche les noms d’utilisateur et leurs mots de passe (sous forme de
hash) à partir de la table "users".
Utilisateur associé : 1337
Hash analysé : 8d3533d75ae2c3966d7e0d4fcc69216b
Mot de passe en clair : charley
QUESTIONS DE REFLEXE /
1/ L’utilisation de SQL dans les applications web rend les sites vulnérables si les entrées utilisateurs
ne sont pas correctement filtrées.
Le risque est élevé : les attaquants peuvent modifier, voler ou supprimer des données.
2/ Protéger les sites contre les injections SQL nécessite une bonne hygiène de codage et de sécurité.
ON PEUT Filtrer les entrées utilisateur, utiliser des requêtes préparées (paramétrées), activer les
firewalls applicatifs, et désactiver les fonctionnalités inutiles de la base de données.