🎥 Du login à l’admin : une injection SQL en direct et sans fioritures (Format Vidéo)
Comment une simple erreur dans la logique d’authentification a mené à un compte admin.
Introduction : de la reco à l’exploitation
🎥 Le contenu de cette newsletter est aussi sous forme de vidéo, mais a la fin de cette newsletter texte, il y a une ressource que tu ne trouveras pas dans la vidéo.
👉 Si tu n’es pas fan du format vidéo, tu peux continuer ci-dessous au format texte.
Le contenu vidéo que tu as au-dessus, tu peux l’avoir en grande quantité, sur plein de sujets, via ce lien => 👉 Zeroday Circle
——
Reprennons, on venait tout juste de finir la phase de reconnaissance.
Énumération des pages, des endpoints, identification de /account, quelques tests manuels… rien de bien méchant.
Mais en regardant de plus près la console Network après une tentative de login classique, on remarque un comportement intéressant :
Statut HTTP 401, réponse Invalid email or password.
C’est propre en apparence, car le message d’erreur reste générique. Pas d’indication sur ce qui est faux entre l’email et le mot de passe.
Mais le vrai test allait venir : et si ce champ était vulnérable à une injection SQL ?
Étape 1 : hypothèse sur la requête SQL
Quand une application web vérifie une authentification, une implémentation naïve pourrait ressembler à ceci :
SELECT * FROM users WHERE email = '$EMAIL' AND password = '$PASSWORD';Si les champs $EMAIL et $PASSWORD ne sont pas correctement échappés ou paramétrés via des requêtes préparées, on peut envisager d’interférer avec la logique SQL.
Étape 2 : payload basique d’injection
Test injecté dans le champ email :
<simple quote> OR 1=1 --Ce qui, intégré à la requête SQL, donne :
SELECT * FROM users WHERE email = <simple quote><simple quote> OR 1=1 --<simple quote> AND password = <simple quote>bidon<simple quote>;Résultat : la condition OR 1=1 rend la clause toujours vraie.
Le -- commente le reste de la requête SQL.
Étape 3 : validation de l’hypothèse
En soumettant ce login falsifié via l’interface web (et non en ligne de commande), on obtient une réponse inattendue :
✅ Authentification réussie.
Non seulement l’injection a fonctionné, mais le système nous a connecté directement… en tant qu’admin.
Très probablement parce que c’était la première ligne de la table users, donc l’admin par défaut.
Étape 4 : post-exploitation immédiate
Passer admin, c’est l’entrée dans une nouvelle phase du pentest :
Accès à des endpoints /admin ou /settings jusqu’ici inaccessibles
Surface d’attaque augmentée (uploads, paramétrage, gestion des utilisateurs)
Possibilité de pivoter vers d’autres types d’attaques (RCE, SSRF, XSS stockée, etc.)
On passe d’un simple test de formulaire… à un contrôle total du back-office.
Étape 5 : pourquoi ça marche (encore) en 2025 ?
Parce que :
L’application ne filtre ni guillemets, ni opérateurs logiques
Il n’y a aucune requête préparée
L’ORM, s’il est utilisé, est mal configuré
Aucun contrôle ne vérifie si une clause WHERE est injectée dynamiquement
Et surtout : aucune trace dans les logs tant qu’on ne les regarde pas de très près.
Étape 6 : contre-mesures immédiates
Utiliser systématiquement des requêtes préparées ou des ORM bien configurés
(Ex : SQLAlchemy, Doctrine, Prisma)
Ne jamais construire de requêtes SQL à la main à partir d’input utilisateur
Appliquer des règles WAF côté proxy (mod_security, OPNsense, AWS WAF…)
Monitorer les requêtes anormales côté base (via logs ou outils type pgAudit)
Cloisonner les privilèges : un compte de service utilisé pour l’authent ne devrait pas pouvoir faire de SELECT * sur tous les utilisateurs.
Étape 7 : vers l’exploitation complète
Maintenant que nous sommes admin, on va chercher :
Les interfaces permettant de téléverser du contenu
Les logs internes
Des clés API, tokens JWT, ou secrets exposés
Des endpoints GraphQL ou Swagger en accès admin
Des fonctions de changement d’email ou de reset mot de passe
Chaque nouvelle page peut cacher une nouvelle faille.
Et chaque privilège est une porte de sortie pour une élévation future.
En résumé
Une injection SQL sur un login, c’est vieux comme le web…
Mais tant que certains copient-collent des requêtes SQL dans leurs backends,
les pentesters auront du boulot.
📌 Dans une prochaine édition, on détaillera :
Comment utiliser sqlmap pour automatiser l’exploitation
Comment construire un rapport de pentest professionnel, avec scoring CVSS et remédiation
En attendant… faites attention à vos OR 1=1 😉
À relire, à tester, à diffuser aux devs de votre équipe.
Et si tu veux t’entraîner sur ce type de cas réels avec nous, c’est juste en dessous.
La ressource que tu ne trouveras pas dans la vidéo en début de cette newsletter !
👉 Rejoindre la communauté Zeroday Circle