Des guillemets.
Un accès admin.
Un payload dans le champ identifiant suffit à réécrire la requête SQL. La vérification du mot de passe disparaît. L'attaquant entre en tant qu'admin sans connaître le moindre credential.
Un formulaire de connexion standard
La porte d'entrée de l'application avec un identifiant et mot de passe
Chaque champ de saisie est une surface d'attaque
Formulaires de connexion, barres de recherche, filtres, paramètres d'URL... Partout où une valeur utilisateur est transmise à une base de données. Si le code concatène directement l'entrée dans la requête SQL, la faille existe par construction.
Chiffres clés
#0
OWASP Top 10
Injection · A03:2021
≤ 0 min
Pour exploiter
un endpoint vulnérable
0%
Des apps vulnérables
qui concaténent l'input
0 ligne
Pour corriger
avec une requête paramétrée
Démo technique
Testez par vous-même
Cette simulation vous permet d'injecter un payload SQL réel et d'observer la requête générée en direct. Réservée aux équipes techniques et aux formateurs.
SQL Injection
Connexion falsifiée par payload
SQL généré :
SELECT * FROM users WHERE email = '' AND password = '';
Payload d'authentification
' OR '1'='1' --
Cette chaîne force la condition à vrai, contournant l'authentification si la requête n'est pas paramétrée.
Pourquoi c'est critique
Ici, l'application utilise directement les valeurs saisies pour construire une requête SQL. Un attaquant peut modifier la requête et se connecter comme un autre utilisateur.
Pour un décideur, cela signifie que des données sensibles peuvent être exposées sans que le code sache qu'il a été manipulé.
Comment se protéger
- Ne jamais concaténer du texte utilisateur dans une requête SQL.
- Utiliser des requêtes paramétrées.
- Valider et normaliser les entrées.
- Limiter les permissions de la base de données.
SELECT * FROM users WHERE email = $1 AND password = $2; -- valeurs liées sans concaténation