Qu’est-ce qu’une injection SQL ? Exemples et conseils de prévention

L’injection SQL (SQLi) est une cyberattaque qui consiste à injecter du code SQL malveillant dans des applications web vulnérables. Cela permet aux attaquants d’interférer avec les requêtes de la base de données et de les manipuler afin d’obtenir un accès non autorisé au serveur. Selon la commande utilisée, une attaque par injection SQL réussie peut avoir des conséquences dévastatrices, entraînant une perte de revenus et de réputation pour les entreprises.

L’injection SQL fait partie des principales vulnérabilités en raison de son impact et des nombreuses façons d’identifier et d’exploiter les serveurs et les applications. Cependant, les développeurs ont apporté plusieurs améliorations pour détecter les attaques SQLi et s’en protéger.

Comment fonctionne l’injection SQL ?

Le langage SQL (Structured Query Language) est un langage standardisé utilisé pour accéder aux bases de données et les manipuler, afin de créer des vues de données personnalisables pour chaque utilisateur. Si l’application et le code ne sont pas correctement nettoyés, du code malveillant peut être injecté dans les sections de saisie et les champs de formulaire des sites web et des applications.

L’injection SQL se produit lorsque des attaquants identifient et insèrent, ou « injectent », des requêtes SQL malveillantes dans des champs de saisie non sécurisés, comme les champs de nom d’utilisateur et de mot de passe ou les barres de recherche. La requête est envoyée à la base de données principale, qui accepte alors le code comme une demande légitime et renvoie les informations au demandeur.

Les attaques SQLi réussies peuvent permettre d’obtenir un accès non autorisé, de récupérer des informations sensibles comme des identifiants et de manipuler des données, par exemple en ajoutant ou en supprimant des données, ou en supprimant des fichiers et des dossiers :

• Voler des identifiants : Les attaquants peuvent utiliser des requêtes SQLi pour accéder aux noms d’utilisateur et aux mots de passe et les voler.
• Accéder aux sites web et aux applications : Les champs de connexion, comme ceux du nom d’utilisateur et du mot de passe, peuvent être contournés à l’aide d’une requête SQL, telle que ‘OR 1=1 — dans les champs du nom d’utilisateur et du mot de passe. Ce code tromperait l’application et l’amènerait à exécuter une requête qui renvoie toujours la valeur « vrai », permettant à l’attaquant d’usurper l’identité d’un utilisateur valide et d’accéder à l’application.
• Modifier les données : Les applications vulnérables aux injections SQL peuvent permettre à des acteurs malveillants d’accéder aux données de la base, notamment à des informations sensibles comme des données de santé et des données financières. Si l’attaquant obtient des privilèges élevés grâce à l’exploitation SQLi, il peut ajouter, modifier ou supprimer des données.

L’injection SQL peut prendre plusieurs formes et compte parmi les vulnérabilités les plus exploitées de l’histoire récente. Cependant, des progrès considérables ont également été réalisés pour détecter les erreurs dans le code des applications et empêcher leur exploitation.

Types d’attaques par injection SQL

Les attaques par injection SQL prennent de nombreuses formes, des types courants comme les injections fondées sur les erreurs, fondées sur UNION et les SQLi aveugles, jusqu’aux attaques hors bande, plus rares :

• Injection SQL fondée sur les erreurs : Les SQLi fondées sur les erreurs reposent sur la collecte, par les attaquants, d’informations sur la base de données grâce à l’analyse des messages d’erreur générés par celle-ci. Dans certains cas, ces messages fournissent des informations précieuses aux acteurs malveillants et les aident à recenser les bases de données vulnérables.
• Attaques fondées sur UNION : Les SQLi fondées sur UNION sont une technique d’injection SQL qui utilise l’opérateur SQL UNION pour combiner les résultats de plusieurs instructions SELECT. Ces attaques peuvent récupérer des données provenant de différentes tables de la base de données dans un résultat unique.
• Injection SQL aveugle : Les SQLi aveugles sont plus difficiles à exploiter que les attaques fondées sur les erreurs ou sur UNION, notamment parce qu’aucune donnée n’est transmise : il est impossible de voir le résultat d’une tentative d’exploitation, d’où le terme « aveugle ». Elles interagissent plutôt avec la base de données en envoyant des charges utiles afin d’observer la réponse de l’application.
  Ces charges utiles sont fondées sur le temps ou sur des valeurs booléennes. Les attaques SQLi aveugles fondées sur le temps cherchent à provoquer un délai, tandis que les attaques fondées sur des valeurs booléennes entraînent une modification de la réponse HTTP de l’application.
• SQLi hors bande : Les SQLi hors bande sont moins courantes que les autres types et ne fonctionnent que si certaines fonctionnalités du serveur de base de données sont activées. Les attaques hors bande ne reposent ni sur les requêtes de la base de données, ni sur les messages d’erreur, ni sur les réponses HTTP. Elles s’appuient plutôt sur le serveur pour créer des requêtes DNS ou HTTP et forcer l’application à envoyer des données vers un point de terminaison distant qu’elles contrôlent.

Quel que soit le type d’injection SQL exploité, l’objectif reste le même : obtenir un accès non autorisé aux applications et exfiltrer toutes les données jugées utiles ou susceptibles d’avoir le plus d’impact. Au fil des ans, nous avons tous été victimes d’une ou plusieurs fuites de données dues à une base de données vulnérable aux injections SQL.

3 exemples d’exploitation des vulnérabilités d’injection SQL par des attaquants

Par le passé, l’injection SQL était très répandue. À un moment donné, elle occupait la première place du classement OWASP Top 10 des vulnérabilités des applications web. Cela s’expliquait par la présence de vulnérabilités d’injection SQL dans la plupart des applications et par le fait que les développeurs n’appliquaient pas les bonnes pratiques, comme les techniques de nettoyage des entrées. Cette situation a entraîné plusieurs importantes fuites de données, notamment chez Heartland Payment Systems, Sony Pictures et Equifax :

• Heartland Payment Systems : En 2008, des attaquants ont découvert une vulnérabilité d’injection SQL sur une page de connexion. Ils ont ensuite utilisé du code SQL malveillant, comme user ‘OR 1=1 – dans les champs du nom d’utilisateur et du mot de passe. Une fois traitées par la base de données, ces requêtes renvoyaient la valeur « vrai », ce qui permettait d’obtenir un accès et de voler des données sensibles sur les utilisateurs, comme des numéros de sécurité sociale et d’autres informations, afin de créer leurs propres cartes de crédit.
• Sony Pictures : Un groupe de hackers connu sous le nom de LulzSec s’est introduit sur le site web de Sony Pictures et a récupéré des bases de données contenant les informations personnelles non chiffrées de plus d’un million de personnes. Le groupe a affirmé qu’il aurait pu « prendre jusqu’à la dernière information » s’il l’avait voulu. Selon l’endroit du site où la charge utile a été exécutée, le groupe de hackers a probablement soumis une entrée telle que ‘ UNION SELECT username, password FROM users– pour voler les données des utilisateurs. Cette commande récupère le contenu d’une table de base de données appelée users et de deux colonnes appelées username et password.
• Equifax : En mai 2017, des acteurs malveillants ont découvert une vulnérabilité dans une application appartenant à Equifax, qui leur permettait d’exécuter des commandes à distance. Ils ont ensuite exploité cette faille pour envoyer des commandes SQL spécialement conçues au serveur et accéder aux données personnelles de près de 150 millions de personnes, ce qui en a fait l’une des plus grandes fuites de données de l’histoire.

L’injection SQL peut être dévastatrice pour les organisations. Cependant, en adoptant une approche proactive et en détectant les vulnérabilités avant les cybercriminels, vous pouvez empêcher une telle situation.

Signes courants indiquant que votre site web est vulnérable aux injections SQL

Pour rechercher des vulnérabilités d’injection SQL, vous pouvez utiliser plusieurs outils et techniques, notamment des scanners de vulnérabilités. Vous pouvez également effectuer des évaluations, comme des tests d’intrusion, ou procéder à des revues de code. Bien que ces outils nécessitent des professionnels qualifiés, quelques autres éléments peuvent être vérifiés.

Voici les signes courants indiquant que votre site web pourrait être vulnérable :

• Messages d’erreur contenant des informations sur la base de données : Lorsque vous saisissez certains caractères, comme une apostrophe ou une quote simple ( ‘ ), dans des formulaires ou des barres de recherche, l’application affiche des messages d’erreur contenant des informations sur la base de données SQL, comme le type ou la version de SQL, des informations sur les colonnes et les tables, ou des parties de la requête SQL.
• Comportement inattendu : La saisie de certains caractères dans les champs de saisie amène l’application à renvoyer des résultats inattendus, comme l’affichage d’une grande quantité de données ou le plantage du site web.
• Nombre inhabituellement élevé de requêtes vers la base de données : Lorsque vous surveillez l’activité de votre base de données, vous pouvez remarquer une hausse soudaine du nombre de saisies ou de requêtes des utilisateurs, ou constater que des données semblent avoir été consultées ou modifiées. Cela peut être dû à une vulnérabilité que quelqu’un tente d’exploiter.
• Manipulation non autorisée des données : Des données sensibles de votre base de données semblent avoir été modifiées ou consultées sans action apparente de la part d’un utilisateur.

Tester manuellement les champs de saisie de sites web, comme les barres de recherche et les écrans de connexion, les paramètres d’URL, voire la base de données directement, à l’aide de chaînes d’injection SQL simples — comme ” ‘ OR ‘1=’1 ” — et vérifier tout comportement inattendu peut suffire à détecter une vulnérabilité SQLi.

3 conseils pour empêcher les injections SQL dans les applications web

Au fil du temps, la sécurité des applications web s’est considérablement améliorée. Les développeurs sont devenus plus conscients des vulnérabilités d’injection SQL et ont mis en place diverses mesures de prévention. Ces stratégies comprennent notamment la validation des entrées, les pare-feu d’applications web et les requêtes paramétrées :

• Nettoyer les entrées : Inspectez et surveillez régulièrement toutes les zones de votre application qui autorisent la saisie par les utilisateurs et interagissent avec la base de données. Veillez à supprimer ou « nettoyer » les entrées en supprimant tout caractère dangereux afin d’empêcher l’utilisation de code malveillant. Créez une liste d’autorisation pour déterminer les entrées valides et rejetez toute entrée suspecte.
• Installer un pare-feu d’applications web : Déployez un pare-feu d’applications web ou « WAF » pour détecter et bloquer les attaques courantes comme les injections SQL. Les WAF surveillent le trafic web à la recherche d’activités anormales. Le pare-feu peut alerter les équipes informatiques en cas de requêtes ou de schémas inhabituels associés aux SQLi.
• Utiliser des requêtes paramétrées : Les requêtes paramétrées ou instructions préparées utilisent des espaces réservés pour les paramètres au lieu de valeurs, séparant ainsi la logique SQL des données transmises. La base de données traite donc la saisie comme des données et non comme du code exécutable.

Prendre ces mesures et effectuer régulièrement des contrôles de sécurité ainsi que des tests d’intrusion peut réduire considérablement le risque d’exposition de vos applications à une injection SQL. Ces approches préventives ont rendu les injections SQL plus difficiles à détecter et à exploiter, les faisant passer de la première à la troisième place du classement OWASP Top 10.

Pour plus de conseils sur la prévention des attaques par injection SQL, notamment une liste d’outils open source, consultez cet article.

Foire aux questions

Voici quelques questions fréquemment posées sur les injections SQL :

1. Toutes les versions de SQL sont-elles vulnérables aux injections SQL ?
   Oui. Même si la syntaxe des requêtes peut varier, toutes les bases de données SQL, comme MySQL, Oracle, PostgreSQL, NoSQL et d’autres, peuvent être vulnérables aux injections SQL.
2. Quelles applications sont concernées ?
   Tout site web ou toute application qui interagit avec une base de données sans bénéficier des protections adéquates est exposé à une attaque SQLi. Cela inclut les applications axées sur les données, comme les réseaux sociaux, les sondages, les applications de recherche et les applications de génération de rapports.
3. Comment tester la présence d’une injection SQL ?
   Plusieurs outils et scanners permettent de tester toutes les vulnérabilités des applications web. Cependant, les tests peuvent également être effectués manuellement en insérant des charges utiles SQL dans chaque point d’entrée de l’application. Ces points d’entrée permettent la saisie par les utilisateurs, notamment dans les forums, les sections de commentaires et les pages de connexion.

Pour obtenir les meilleurs résultats, faites appel à une entreprise spécialisée dans les tests d’intrusion d’applications et effectuant régulièrement des tests sur vos applications.

En bref : l’injection SQL est ancienne, mais toujours dangereuse

Même si les attaques par injection SQL sont moins courantes qu’il y a 10, voire 20 ans, cette vulnérabilité peut toujours causer des dommages considérables si elle est découverte et exploitée. Les organisations doivent utiliser des techniques de codage sécurisé et tester régulièrement leurs applications afin de prévenir les vulnérabilités SQLi.

Pour voir un exemple majeur de la façon dont des chercheurs en sécurité ont contourné les contrôles de la TSA.