Table des matières
🎯 Objectif
Notre développeur web n’est pas très doué en matière de sécurité… Saurez-vous afficher le flag afin que nous puissions lui montrer qu’il faut faire des efforts ?
Note : Aucun bruteforce n’est nécessaire.
Une variante de cette Ă©preuve est disponible ici : Scully 2.
🔍 Découverte
Le site web présente un formulaire de connexion simple avec :
- Un champ username
- Un champ password
- Un bouton de connexion
L’inspection du code source rĂ©vèle un traitement classique des identifiants via une requĂŞte POST vers une API.
đź’‰ Exploitation
Première analyse
L’application utilise une validation cĂ´tĂ© serveur qui semble vulnĂ©rable aux injections SQL classiques.
Solution
- Dans le champ “Nom d’utilisateur” :
' OR 1=1 --
- Dans le champ “Mot de passe” :
fsdfdsdf
Cette injection fonctionne car :
- Le
'
ferme la chaîne de caractères dans la requête SQL OR 1=1
ajoute une condition toujours vraie--
commente le reste de la requĂŞte SQL
🎉 Flag
Flag obtenu après connexion réussie
đź“ť Notes
- L’injection SQL de base
' OR 1=1 --
fonctionne directement, indiquant une absence totale de protection - Aucune validation des entrĂ©es n’est effectuĂ©e cĂ´tĂ© serveur
- Pas besoin de techniques avancées ou de bruteforce
đź”’ Correction
Pour sécuriser ce type de vulnérabilité :
- Utiliser des requêtes préparées
- Échapper les caractères spéciaux
- Mettre en place une validation côté serveur
- Utiliser un ORM pour la gestion des requĂŞtes SQL
- Implémenter une limitation du nombre de tentatives de connexion