Injection SQL : Comment cela fonctionne-t-il et comment le prévenir ?

L'injection SQL (ou SQLi en abrégé) est l'une des plus anciennes astuces du manuel du pirate informatique, mais elle reste incroyablement courante et dangereuse. En bref, il s'agit de tromper une base de données pour qu'elle révèle des choses qu'elle ne devrait pas révéler.

Dans cet article, je vais vous expliquer ce qu'est l'injection SQL, les différentes façons dont les attaquants l'utilisent, quelques exemples concrets qui ont causé de sérieux dégâts et, peut-être le plus important, comment vous pouvez l'éviter. Que vous soyez développeur ou simplement curieux de savoir comment les choses se cassent sur Internet, vous en sortirez avec une solide compréhension de SQLi (sans vous endormir à mi-parcours, je vous le promets).

Qu'est-ce que l'injection SQL ? 

L'injection SQL est un type d'attaque qui se produit lorsque quelqu'un trouve un moyen d'altérer les requêtes SQL que votre application envoie à la base de données. Normalement, ces requêtes sont censées faire des choses comme récupérer le profil d'un utilisateur ou mettre à jour une liste de produits. Mais avec SQLi, un pirate peut injecter des éléments malveillants de code SQL dans vos champs de saisie (comme les barres de recherche ou les formulaires de connexion), et soudain, la base de données fait exactement ce que ils veulent à la place.

Pourquoi cela fonctionne-t-il ? 

Parce que, quelque part, l'application fait un peu trop confiance à l'entrée de l'utilisateur et la traite comme du texte inoffensif plutôt que comme un code exécutable potentiel. C'est comme si vous laissiez quelqu'un remplir un formulaire et que vous colliez ensuite ce qu'il a écrit directement dans une console de commande.

Pourquoi est-ce mauvais ?

L'injection SQL est dangereuse car elle peut être utilisée pour visualiser ou voler des données privées (comme les noms d'utilisateur, les mots de passe ou les informations relatives aux cartes de crédit), contourner les écrans de connexion, supprimer ou modifier des données, et même prendre le contrôle total du serveur de la base de données dans les pires scénarios.

Alors oui, SQLi est mauvais, et ce n'est même pas un problème de sécurité récent, mais vous seriez surpris de voir combien d'applications ne sont pas correctement protégées contre lui.

Types d'injection SQL

Selon la manière dont l'attaquant interagit avec votre application et le type de retour d'information qu'il obtient, SQLi se présente sous différentes formes. Il y a trois types principaux de problèmes que vous pouvez rencontrer :

SQLi en bande

Il s'agit du type le plus simple. L'attaquant envoie une requête SQL malveillante et reçoit les résultats en retour par l'intermédiaire de l'application. C'est rapide et souvent très efficace.

• SQLi basé sur les erreurs: Cette technique repose sur le fait que la base de données renvoie utilement des messages d'erreur. Ces erreurs peuvent révéler une foule d'informations utiles, comme les noms des tableaux ou la structure des requêtes, ce qui permet à l'attaquant de planifier plus facilement son prochain coup.

• SQLi basé sur l'union: Ici, l'attaquant utilise l'opérateur UNION pour combiner sa propre requête avec celle que votre application exécute. Il s'agit d'un moyen astucieux d'extraire des données supplémentaires de la base de données et de les insérer en douce dans la réponse.

SQLi inférentiel (aka Blind SQLi)

Celui-ci est plus sournois. Au lieu de voir directement les résultats de sa requête, l'attaquant observe le comportement de l'application pour comprendre ce qui se passe sous le capot.

• SQLi basé sur les booléens (basé sur le contenu): L'attaquant modifie la requête en y ajoutant des conditions qui sont soit vraies, soit fausses (comme 1=1 ou 1=2) et observe comment la page change. Le chargement se fait-il normalement ? Afficher une erreur ? Agir bizarrement ?
• SQLi basé sur le temps: Cette technique consiste à ajouter des délais à la requête (par exemple WAITFOR DELAY '00:00:05' ) et à utiliser le temps de réponse pour déterminer si une condition est remplie.

SQLi hors bande (lorsque les choses deviennent fantaisistes)

Celui-ci est moins courant, mais il vaut la peine d'être connu. SQLi hors bande ne dépend pas des réponses immédiates de l'application. Au lieu de cela, l'attaquant utilise d'autres canaux comme les requêtes DNS ou HTTP pour extraire des données. Il est généralement réservé aux situations où un retour d'information direct n'est pas possible mais où le serveur de base de données dispose d'un accès à l'internet (et dans 90 % des cas, il ne devrait probablement pas y avoir d'accès).

Techniques courantes d'injection SQL

Nous avons donc appris à connaître les trois types d'injection SQL. Mais comment les attaquants y parviennent-ils dans la pratique ?

OU 1=1 attaque

Celui-ci est un classique. Imaginez un formulaire de connexion dans lequel vous devez saisir votre nom d'utilisateur et votre mot de passe. Un attaquant pourrait entrer quelque chose comme ceci :

' OR 1=1 --

La requête SQL se présente comme suit :

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';

Comme 1=1 est toujours vrai, la base de données renvoie tous les utilisateurs, et -- transforme le reste de la requête en commentaire. Si aucune limite n'est fixée, l'attaquant peut se connecter sans même connaître un nom d'utilisateur valide.

Source : vmware

Injection de commentaires

Comme nous l'avons vu plus haut, les caractères-- ou /* */ sont utilisés pour commenter des parties d'une instruction SQL. Les attaquants s'en servent pour supprimer toute clause supplémentaire susceptible d'interrompre leur charge utile injectée. Par exemple, s'ils ne connaissent pas la structure complète de la requête originale, ils peuvent simplement la couper et la rendre à nouveau syntaxiquement valide.

Instructions SQL par lots

Certaines bases de données permettent d'exécuter plusieurs instructions SQL dans une seule requête, en les séparant par un point-virgule. Cette fonctionnalité peut être utilisée par les pirates pour faire toutes sortes de dégâts, comme la modification de données ou même l'abandon de tableaux si l'application ne le restreint pas.

'; DROP TABLE users; --

Attaques basées sur l'UNION

En injectant une instructionUNION SELECT , les attaquants peuvent combiner leur requête malveillante avec la requête légitime et extraire des résultats d'autres tableaux, comme des données utilisateur sensibles, des mots de passe ou des informations sur les cartes de crédit. Il s'agit essentiellement d'utiliser une requête existante pour obtenir des données sur les primes.

Injection SQL aveugle

Nous l'avons déjà mentionné. Même si l'application n'affiche pas d'erreurs ou ne renvoie pas de résultats, les attaquants peuvent toujours extraire des données petit à petit en observant le comportement. C'est plus lent et plus fastidieux, mais cela fonctionne. Cette opération est souvent automatisée à l'aide d'outils qui peuvent essayer des centaines de requêtes et des réponses basées sur le temps.

Injection SQL stockée

Le code SQL malveillant est enregistré dans la base de données, par exemple dans un profil d'utilisateur ou un commentaire, et exécuté plus tard lorsque quelqu'un consulte ces données.

Attaques par injection SQL dans le monde réel

L'injection SQL peut sembler être un truc de hacker de niche, mais elle a causé des dégâts bien réels au fil des ans. Et par dommages, j'entends des millions d'enregistrements d'utilisateurs exposés, des amendes considérables et des titres qui n'ont pas fait les faveurs des services de marketing.

Guess.com (2002)

Il s'agit d'un exemple précoce qui a attiré l'attention des gens. Un chercheur en sécurité a exploité une faille d'injection SQL et a eu accès à plus de 200 000 dossiers de clients, y compris des détails de cartes de crédit. La bonne nouvelle, c'est qu'elle a été découverte et signalée par un hacker éthique. 

Systèmes de paiement Heartland (2009)

Il s'agit d'une violation massive affectant un processeur de paiement et plus de 130 millions de numéros de cartes de crédit ont été volés. Les attaquants ont utilisé l'injection SQL pour s'implanter, puis sont montés en puissance à partir de là. Celle-ci est souvent citée comme l'une des plus grandes violations de données jamais survenues.

Yahoo ! Voices (2012)

Les attaquants ont exploité une faille d'injection SQL basée sur UNION et ont exposé 450 000 noms d'utilisateur et mots de passe en texte clair. Oui, vous avez bien lu, il s'agit d'informations d'identification brutes en texte clair. Cette violation était d'autant plus embarrassante que Yahoo ! était une grande entreprise technologique et que le stockage de mots de passe non cryptés est une chose à ne pas faire, même selon les normes de 2012.

TalkTalk (2015)

TalkTalk est un fournisseur de télécommunications britannique très connu qui a été victime d'une attaque par injection SQL assez simple. Environ 157 000 dossiers de clients ont été compromis et la société a été condamnée à une amende de 400 000 livres sterling. L'un des agresseurs n'avait que 17 ans.

Gab (2021)

Les hacktivistes ont utilisé l'injection SQL pour exfiltrer 70 Go de données, y compris des messages privés et des mots de passe hachés. La violation a eu des répercussions politiques et les retombées ont suscité un examen encore plus approfondi de la position générale de Gab en matière de sécurité.

Comment prévenir l'injection SQL

Maintenant que nous nous sommes un peu effrayés avec toutes ces brèches dans le monde réel, parlons des solutions. La bonne nouvelle, c'est que la prévention des injections SQL n'a rien de sorcier. La plupart du temps, il s'agit de ne pas faire confiance aux commentaires des utilisateurs et de s'en tenir aux meilleures pratiques. Voici ce que vous pouvez faire :

Utiliser des requêtes paramétrées

C'est la règle numéro un. Ne construisez jamais de requêtes SQL en collant des chaînes de caractères ensemble. Utilisez plutôt des espaces réservés et transmettez les données de l'utilisateur en tant que paramètres. La plupart des frameworks et des bibliothèques facilitent grandement cette tâche.

Par exemple dans Node.js avec pg (PostgreSQL) :

client.query('SELECT * FROM users WHERE id = $1', [userId]);

Cela signifie essentiellement à la base de données, "Voici la structure de la requête, et voici quelques données, ne les mélangez pas."

Utilisez intelligemment les procédures stockées

Les procédures stockées peuvent être utiles, mais seulement si elles évitent également le SQL dynamique. L'idée est que la logique SQL se trouve dans la base de données et que votre application se contente d'appeler ces morceaux de logique prédéfinis et sûrs.

Si vous souhaitez apprendre à créer, mettre à jour et exécuter des fonctions et des procédures stockées, consultez notre cours Writing Functions and Stored Procedures in SQL Server.

Valider et assainir les entrées

Si votre application attend un nombre, assurez-vous qu'il s'agit bien d'un nombre. N'acceptez pas aveuglément tout ce que l'utilisateur vous propose. Utilisez des contrôles de type, des limites de longueur et des listes d'autorisation (par exemple, n'autorisez que les bonnes valeurs connues) lorsque c'est possible.

Les caractères d'échappement (comme les guillemets) peuvent également être utiles, mais ils ne remplacent pas les requêtes paramétrées.

Utilisez un pare-feu d'application Web (WAF)

Un WAF peut servir de première ligne de défense, en particulier contre les schémas d'attaque connus. Il peut aider à bloquer le trafic malveillant avant même qu'il n'atteigne votre application. Il n'est pas infaillible mais utile, c'est un peu comme un filtre anti-spam pour votre SQL.

Appliquer le principe du moindre privilège

Votre application web ne doit pas se connecter à la base de données avec des droits d'administrateur. Limitez ce que chaque utilisateur ou service peut faire. Par exemple, si votre application n'a besoin que de lire des données, ne lui donnez pas la permission de supprimer des tableaux. Moins il est puissant, moins une injection peut faire de dégâts.

Test et détection des injections SQL

Même si vous pensez que votre code est sûr, il vaut la peine de le tester comme le ferait un attaquant. L'injection SQL passe souvent inaperçue, en particulier dans les grandes bases de code ou les systèmes existants. Il existe des outils et des techniques qui facilitent grandement la détection et avec lesquels il est assez amusant de jouer.

Tests manuels

Parfois, le moyen le plus rapide de repérer un trou est de le creuser. Essayez de saisir ' OR 1=1 -- or '; DROP TABLE users; -- dans des champs de formulaire, des URL ou toute autre zone de saisie et voyez comment l'application réagit. Si vous obtenez des erreurs bizarres, des données inattendues ou des messages de réussite mystérieux, il se peut que vous ayez trouvé quelque chose de suspect.

Conseil de pro : Testez toujours dans un environnement de développement ou de mise en scène. 

Scanners automatisés

Il existe de nombreux outils qui se chargent de cette tâche à votre place. Il y en a de bonnes :

• sqlmap: Une bête open-source qui automatise la détection et l'exploitation (dans des contextes de tests éthiques).
• Burp Suite: Excellent pour la sécurité des applications web en général, avec des extensions pour la détection de SQLi.
• OWASP ZAP: Gratuit et adapté aux débutants, il permet de trouver toutes sortes de vulnérabilités sur le web.

Ces outils simulent des attaques, signalent les points d'injection potentiels et peuvent parfois suggérer des correctifs.

Analyse du journal

Autre astuce sournoise : surveillez les journaux de votre base de données. Des requêtes qui échouent à plusieurs reprises, des schémas syntaxiques bizarres ou un afflux de requêtes contenant ', --, ou UNION SELECT sont autant de signaux d'alarme.

Conclusion

L'injection SQL n'est pas près de disparaître, et c'est l'une des menaces qui ne vieillit jamais. C'est simple, c'est puissant et si vous ne faites pas attention, cela peut causer de sérieux dommages. Le fait est que SQLi est totalement évitable. En utilisant des requêtes paramétrées, en validant les entrées, en appliquant le principe du moindre privilège et en effectuant des tests réguliers, vous pouvez protéger vos applications et vos utilisateurs de l'impact dévastateur d'une attaque par injection SQL. 

Rappelez-vous que personne n'attend la perfection, mais avec un peu d'efforts proactifs, vous pouvez garder votre base de données en sécurité et rayer ce point de votre liste de contrôle de sécurité. Et si vous vous intéressez sérieusement au langage SQL et que vous souhaitez faire valoir vos compétences auprès d'employeurs potentiels, jetez un coup d'œil à notre certification SQL Associate! Il montrera que vous êtes capable d'utiliser le langage SQL pour extraire les données appropriées d'une base de données et de l'utiliser pour répondre à des questions courantes sur les données.