Sqlmap : automatiser la détection et l'exploitation des injections SQL

Sqlmap reste l’outil de référence quand il s’agit de transformer une simple faille d’injection SQL en démonstration concrète d’impact. Il ne se contente pas de signaler le problème : il l’exploite, cartographie la base de données, extrait ce qui l’intéresse et, dans certains cas, ouvre une porte vers le système d’exploitation sous-jacent. Dans le quotidien d’un pentest web, c’est souvent l’étape qui fait passer d’une vulnérabilité « théorique » à un risque réel et mesurable.

En fait, sqlmap existe depuis longtemps et continue d’évoluer. Projet open source écrit en Python, il est maintenu activement et intégré par défaut dans Kali Linux. Les pentesters l’utilisent parce qu’il gère une grande partie du travail répétitif et fastidieux : tester des centaines de payloads, deviner le type de base de données, contourner certains filtres basiques. Du coup, on gagne du temps pour se concentrer sur ce qui compte vraiment : l’impact business et les recommandations de remédiation.

sqlmap face aux injections SQL classiques

Une injection SQL se produit quand une application web intègre des données utilisateur directement dans une requête sans les filtrer correctement. L’attaquant peut alors modifier la logique de la requête, lire des données qu’il n’est pas censé voir, ou parfois modifier et supprimer des enregistrements. sqlmap automatise tout ça. Il envoie des payloads ciblés, observe les réponses du serveur et détermine si une injection existe, quel type elle est, et jusqu’où elle peut aller.

Le moteur de détection est particulièrement robuste. Il teste plusieurs approches en parallèle et s’adapte au comportement observé. Une fois la faille confirmée, il passe en mode exploitation et commence à interagir avec la base comme s’il était un utilisateur légitime doté de droits excessifs.

Les techniques que l’outil maîtrise vraiment

sqlmap ne mise pas sur une seule méthode. Il connaît les injections basées sur les erreurs (quand le serveur crache des messages SQL utiles), les UNION qui permettent de fusionner des résultats, les requêtes empilées qui exécutent plusieurs instructions d’un coup, et les deux formes d’injections aveugles : booléennes (le serveur répond différemment selon que la condition est vraie ou fausse) et temporelles (on mesure les délais de réponse pour inférer l’information bit par bit).

Il gère aussi les requêtes inline. Selon le contexte, il choisit la technique la plus efficace ou laisse l’utilisateur forcer une méthode précise avec l’option --technique. Sur une application moderne protégée par un WAF, on combine souvent plusieurs techniques et on fait appel aux scripts de tamper pour modifier les payloads à la volée : remplacer les espaces par des commentaires, changer la casse, utiliser LIKE à la place de l’égalité, etc. Ça passe parfois là où une requête brute se fait bloquer.

Ce qu’on peut vraiment faire une fois connecté

Une fois l’injection exploitée, sqlmap devient un véritable couteau suisse. Il peut lister les bases de données présentes, les tables, les colonnes. Il extrait les utilisateurs, leurs hashes de mot de passe, leurs privilèges. Il est capable de dumper des tables entières ou seulement quelques colonnes stratégiques. Sur MySQL, PostgreSQL ou Microsoft SQL Server, il peut même lire et écrire des fichiers sur le disque du serveur si les droits le permettent.

Certaines configurations permettent d’exécuter des commandes système et de récupérer leur sortie. Dans les scénarios les plus avancés, sqlmap établit une connexion out-of-band et peut même proposer une session interactive ou un tunnel vers Metasploit. Ce n’est pas systématique, mais quand les conditions sont réunies, ça transforme une vulnérabilité web en compromission plus large du serveur.

Et honnêtement, c’est souvent à ce moment-là que le client comprend vraiment le risque. Voir ses propres données sortir en clair ou découvrir qu’un compte admin a été récupéré en quelques minutes, ça marque plus qu’un rapport théorique.

Démarrer simplement sans se perdre

Sur Kali, sqlmap est déjà installé. Ailleurs, un simple git clone du dépôt officiel suffit. La commande de base ressemble à ça :

sqlmap -u "https://exemple.com/page?id=1" --batch --dbs

L’option -u cible l’URL, --batch évite les questions interactives, --dbs demande de lister les bases. Pour les formulaires POST, les cookies ou les en-têtes personnalisés, on passe souvent par un fichier de requête capturé avec Burp ou un proxy :

sqlmap -r requete.txt --cookie="session=xxx" --proxy=http://127.0.0.1:8080

On peut ensuite préciser la base avec -D, lister les tables avec --tables, dumper avec --dump, ou cibler une colonne précise. Les options --current-user, --is-dba ou --hostname donnent rapidement des informations sur le contexte d’exécution. Pour accélérer les choses sur une grosse base, on augmente les threads ou on fixe le SGBD avec --dbms si on le connaît déjà.

Les précautions qui évitent les mauvaises surprises

sqlmap est puissant, mais il reste un outil offensif. L’utiliser sans autorisation écrite et explicite du propriétaire du système est illégal. Même dans un cadre autorisé, il faut rester prudent : certains payloads à haut risque peuvent modifier des données, et un scan trop agressif peut surcharger une application en production.

Dans la pratique, on commence souvent avec un niveau de risque et de verbosité modéré, on observe le trafic via Burp, et on ajuste. Les options --delay et --threads permettent de doser la charge. Garder la session avec --keep-session évite de tout retester à chaque lancement. Et quand on veut repartir de zéro, --flush-session fait le ménage.

sqlmap ne remplace pas la compréhension du contexte applicatif. Sur des applications très complexes ou fortement customisées, le travail manuel reste parfois plus précis. Mais pour la majorité des cas rencontrés en pentest web, il fait gagner un temps considérable et produit des preuves tangibles.

sqlmap dans la réalité des audits de cybersécurité

Aujourd’hui, presque tous les rapports de pentest web qui mentionnent une injection SQL s’appuient sur sqlmap pour quantifier l’impact. Les clients veulent voir concrètement ce qui aurait pu être extrait, modifié ou exécuté. L’outil fournit ces éléments de façon reproductible et documentée.

Il ne fait pas tout seul la sécurité d’une application. Il met simplement en lumière ce qui se passe quand les entrées ne sont pas correctement validées et que les requêtes ne sont pas paramétrées. C’est pour ça qu’il reste un passage presque obligé dans la boîte à outils de quiconque teste régulièrement des applications web : il transforme une vulnérabilité abstraite en scénario d’attaque concret, et ça change la façon dont on priorise les correctifs.