Qu’est-ce que l’injection SQL ? Comment prévenir les attaques SQLi

Les applications Web alimentent notre expérience en ligne jour après jour. Nous nous connectons, interagissons, achetons et regardons des vidéos amusantes sur les chats, le tout à l'aide d'applications Web. Ils fournissent des services commerciaux vitaux et détiennent des données sensibles, mais plus nous utilisons quelque chose, plus il devient vulnérable aux attaques.

Une cyberattaque à surveiller sur les applications qui exploitent les vulnérabilités du langage de requête structuré (SQL) est l’injection SQL courante et dangereuse.

Les attaques par injection SQL entraînent un accès inapproprié aux données, une manipulation, un vol d'identité, une perte financière, une atteinte à la réputation et des conséquences juridiques. Les développeurs et les organisations doivent comprendre ses risques et mettre en œuvre des mesures de sécurité complètes. Des outils tels que les logiciels de pare-feu d'application Web (WAF) et les logiciels d'investigation numérique sont conçus pour se prémunir contre les attaques par injection SQL. Les entreprises peuvent également compter sur des suites complètes de sécurité de sites Web pour protéger leurs applications.

Lisez cette aide-mémoire pour l'injection SQL pour savoir comment les attaques SQL sont exécutées avec des exemples, leurs variantes et comment empêcher de telles attaques.

Pourquoi les attaques par injection SQL sont-elles dangereuses ?

L'injection SQL figure depuis des années dans la liste des 10 principaux risques de sécurité des applications Web de l'Open Worldwide Application Security Project (OWASP). Rien qu’en 2022, l’OWASP a trouvé plus de 274 000 occurrences d’une certaine forme d’injection dans les applications testées ; L'injection SQL et le cross-site scripting (XSS) étaient les plus courants.

Les attaquants peuvent utiliser des injections SQL pour provoquer :

• Erreurs dans les applications Web en modifiant ou en supprimant des informations dans une base de données.
• Violations de données si des pirates informatiques obtiennent un accès non autorisé à des données sensibles stockées dans des bases de données, telles que des informations personnelles, des dossiers financiers ou des mots de passe.
• Systèmes compromis en accédant à des systèmes supplémentaires non autorisés qui utilisent les mêmes bases de données partagées. Cela permet aux attaquants d'étendre leurs attaques à d'autres systèmes sur le même réseau ou d'effectuer un déni de service distribué (DDoS).

Ces actions destructrices portent un préjudice irrévocable aux entreprises. Ces infractions compromettent la confidentialité et l’intégrité des données, entraînant une perte de confiance des clients et une perte de réputation de l’entreprise. Cela ajoute également une charge financière à l’entreprise qui doit faire face aux conséquences.

Exemples réels d'attaques par injection SQL

Cela fait plus de deux décennies que l’injection SQL est apparue pour la première fois. Vingt ans plus tard, cela reste notoire, comme en témoignent les incidents d'injection SQL importants suivants.

• Heartland Payments Systems : en 2008, Heartland Payments Systems a subi l'une des plus grandes violations de données de l'histoire, exposant plus de 130 millions de détails de cartes de crédit et de débit via une attaque SQLi. Heartland a payé des millions d'amendes.
• Yahoo : En 2012, une attaque par injection SQL a compromis les détails des comptes d'utilisateurs Yahoo de près de 5 millions, y compris les adresses e-mail et les mots de passe.
• Freepik : des pirates ont volé les e-mails et les mots de passe de 8,3 millions d'utilisateurs de Freepik et Flaticon en 2020 lors d'une attaque par injection SQL contre le site Web Flaticon de l'entreprise.
• WooCommerce : le populaire plugin WordPress a corrigé une vulnérabilité d'injection SQL qui exposait 5 millions de sites au vol de données.
• BillQuick : les cybercriminels ont exploité une vulnérabilité aveugle de SQL dans la plate-forme de facturation populaire pour propager un ransomware.
• MOVEit : en mai 2023, le gang du ransomware Cl0p a utilisé une vulnérabilité d'injection SQL dans l'outil logiciel de transfert de fichiers géré MOVEit, affectant plus de 1 000 organisations et au moins 60 millions de personnes, ce qui en fait la plus grande violation de données de l'année à ce jour.

Comment fonctionne une attaque par injection SQL ?

Examinons les bases des bases de données et des requêtes SQL que nous utilisons dans les applications Web modernes. Cela nous aidera à mieux comprendre le fonctionnement interne de l’injection SQL.

Tous les sites Web utilisent des bases de données relationnelles, également appelées bases de données SQL, pour stocker des données sur leurs utilisateurs et applications. Il peut s'agir d'informations utilisateur, d'identifiants de connexion, d'informations de paiement ou de tout autre élément concernant l'entreprise. Prenez par exemple un site de commerce électronique. Il stocke les données sur les produits, les comptes d'utilisateurs, les données de commande et les informations de paiement dans sa base de données.

Les sites Web récupèrent ensuite les données de ces bases de données et proposent des contenus ou des services spécifiques aux utilisateurs. Ce processus se produit grâce à SQL, un langage de programmation standardisé utilisé pour gérer les bases de données. Chaque fois que vous avez besoin d'obtenir quelque chose d'une application, par exemple votre historique d'achats, vous adressez en fait une requête à la base de données à l'aide de requêtes SQL, une commande qui demande à une base de données d'effectuer une action spécifique.

Dans le but de rendre les interactions Web transparentes, de nombreux sites Web permettent aux utilisateurs de saisir des données pour effectuer des requêtes SQL. Cela peut inclure des éléments tels que des termes de recherche, des noms d'utilisateur ou des détails de paiement.

Prenons l'exemple du site de commerce électronique. Une simple requête SQL pour afficher votre historique de commandes depuis la base de données avec une table "commandes" (o) et une table "produits" (p) sera la suivante :

Ce code SQL sélectionne l'ID de commande et la date dans la table des commandes, ainsi que le nom et le prix du produit dans la table des produits pour l'ID UTILISATEUR 12345 de la base de données du site Web. En règle générale, l'ID sera basé sur la saisie de l'utilisateur. Des problèmes surviennent lorsque les entrées ne sont pas correctement vérifiées et contrôlées. Les attaquants exploitent cette vulnérabilité pour mener une attaque par injection SQL.

Voici comment cela se déroule généralement.

• Identification des champs de saisie vulnérables : les attaquants commencent par trouver des champs de saisie sur l'application Web dans lesquels ils peuvent potentiellement injecter du code malveillant. Ils soumettent différentes valeurs et voient comment l'application réagit. pour savoir si. Si l'application ne valide pas ou ne nettoie pas correctement l'entrée utilisateur, l'application traite son entrée sous forme de code SQL. Cette vulnérabilité potentielle est utilisée pour l’injection de code.
• Injection de code via la saisie de l'utilisateur : après avoir compris comment l'application gère les saisies, les attaquants construisent une charge utile, qui est un morceau de code SQL malveillant qui tire parti de la vulnérabilité. Cela inclut l'ajout de caractères de contrôle SQL tels que les guillemets simples ('), les guillemets doubles («) ou égal (=) pour modifier la structure de la requête SQL. L'utilisation de ces caractères de contrôle avec des commandes SQL courantes telles que SELECT et FROM permet aux attaquants d'accéder ou de récupérer des données du serveur de base de données.
  
  Ils soumettent ensuite des entrées spécialement conçues ainsi que des demandes légitimes, trompant l'application en lui faisant traiter le code douteux comme une partie légitime de la requête.
• Exécution : la base de données, ignorant l'attaque, traite la requête et exécute le code injecté comme s'il s'agissait d'une requête légitime.
• Exploitation : selon l'intention de l'attaquant, le code SQL injecté peut récupérer des données sensibles, modifier ou supprimer des informations, ou même accorder un accès non autorisé. Cela compromet la sécurité de l'application, exposant potentiellement des informations sensibles.

Exemple d'injection SQL

Prenons l'exemple d'une application Web qui utilise un paramètre d'URL pour récupérer les détails du produit en fonction d'un ID de produit, comme ceci :

http://example.com/products?id=1

Un attaquant pourrait tenter d'injecter du code SQL malveillant pour provoquer une erreur et récupérer des informations telles que celles-ci : http://example.com/products?id=1' OR 1=1; –

Si l'application ne parvient pas à valider et à nettoyer correctement les entrées de l'utilisateur, la requête SQL peut être manipulée comme suit :

SELECT * FROM produits WHERE OR 1=1 ; - - ';

Dans ce cas, la requête d'origine a été conçue pour récupérer un produit avec l'ID 1, mais l'entrée de l'attaquant modifie la requête pour renvoyer tous les produits en raison de l'ajout de 1=1 et du double trait d'union ajouté (- -). Cela annule le guillemet unique de fermeture d'origine et entraîne des conséquences en affichant tous les détails du produit ou en révélant des messages d'erreur que les attaquants peuvent exploiter.

33%

des vulnérabilités critiques des applications Web en 2022 étaient dues à des injections SQL.

Source : Statista

La prévalence généralisée des vulnérabilités SQL et l’attrait de la base de données des applications Web avec toutes ses données critiques pour l’entreprise font de l’injection SQL l’une des cyberattaques les plus persistantes.

Source : Spiceworks

Types d'attaques par injection SQL

Il existe trois principaux types d'attaques par injection SQL basées sur la manière dont les attaquants récupèrent les informations ou interagissent avec la base de données :

1. SQLi classique ou intra-bande
2. SQLi aveugle ou inférentiel
3. SQLi hors bande

1. SQLi classique ou intra-bande

In-band est le type d’attaque par injection SQL le plus courant. Le hacker classique utilise le même canal de communication (in-band) pour injecter du code SQL malveillant et récupérer les résultats. Les deux principales variantes de SQLi intra-bande sont :

SQLi intrabande basé sur l'union

Cette attaque exploite l'opérateur UNION SQL, utilisé pour combiner les données du résultat de deux ou plusieurs instructions SELECT. En procédant ainsi, les attaquants peuvent récupérer des données à partir de tables auxquelles ils n'ont pas directement accès.

SQLi intrabande basé sur les erreurs

Dans cette technique, un attaquant déclenche intentionnellement des erreurs dans une requête SQL pour exploiter les messages d'erreur renvoyés par la base de données. Les erreurs peuvent révéler des informations précieuses sur la structure de la base de données, les noms des tables, les noms des colonnes et parfois les données elles-mêmes. SQLi basé sur les erreurs peut également être exécuté en tant que SQLi hors bande.

2. SQLi inférentiel (aveugle)

Dans un SQLi aveugle, l’attaquant ne peut pas voir directement les résultats de son assaut. Au lieu de cela, ils déduisent des informations en observant le comportement des applications ou les messages d'erreur qui répondent à leurs requêtes. Ce type d'attaque prend beaucoup de temps car les pirates doivent effectuer une série de requêtes SQL pour trouver des vulnérabilités potentielles à exploiter. Deux variantes de SQLi aveugle sont :

SQLi aveugle basé sur le temps

Ici, les attaquants posent des requêtes qui font que la base de données retarde sa réponse avant de réagir. Ils déduisent des informations sur la base de données en prêtant attention au temps de réponse.

SQLi aveugle booléen

Pour SQLi aveugle booléen, les attaquants profitent de la façon dont une application répond aux conditions vraies ou fausses dans les requêtes SQL. Sur la base des réponses de l'application Web, ils déduisent des informations sur la base de données, même si aucune donnée de la base de données n'est renvoyée.

3. SQLi hors bande

Une attaque SQLi hors bande amène l'application à envoyer des données à un point de terminaison distant contrôlé par les pirates. Une attaque comme celle-ci nécessite que les serveurs SQL disposent de certaines fonctionnalités, comme la possibilité d'initier des requêtes réseau externes telles que des requêtes HTTP (Hypertext Transfer Protocol).

Comment prévenir les attaques par injection SQL : aide-mémoire

La prévention de l’injection SQL nécessite une approche à plusieurs niveaux impliquant une pratique de codage sécurisée et une surveillance continue. Voici une aide-mémoire avec les étapes essentielles pour vous protéger des attaques par injection SQL.

Utiliser des instructions préparées

La principale défense contre les attaques par injection SQL consiste en des instructions préparées avec des requêtes paramétrées. Les instructions préparées garantissent que les entrées de l'utilisateur sont traitées comme des données plutôt que comme du code exécutable.

Les développeurs compilent à l'avance les codes SQL pour les requêtes sous forme de modèles avec des espaces réservés pour les valeurs d'entrée de l'utilisateur. Au moment de l'exécution de la requête, les instructions préparées lient les valeurs réelles au lieu des espaces réservés. Cela arrête l'exécution de code malveillant.

Les instructions préparées sont préférées aux instructions SQL dynamiques. Ils écrivent des requêtes SQL pendant le temps d’exécution, ce qui les affaiblit face aux attaques par injection.

Une autre méthode de prévention des injections SQL consiste à utiliser des procédures stockées ou un groupe de codes SQL précompilés qui peuvent être utilisés encore et encore.

Pratiquer la validation des entrées

La validation des entrées implique de vérifier les entrées de l'utilisateur pour s'assurer qu'elles répondent à des critères spécifiques avant le traitement. Une liste verte, également appelée liste blanche, est un aspect clé de la validation des entrées. Ici, seules les valeurs ou modèles prédéfinis et sûrs sont acceptés dans le cadre des requêtes SQL. Toute entrée qui ne correspond pas aux critères définis est rejetée. Cela empêche activement les entrées malignes ou inattendues d’entrer dans le système.

Utiliser des bibliothèques de mappage objet-relationnel

Les bibliothèques de mappage objet-relationnel (ORM) sont des outils précieux pour les développeurs travaillant avec des bases de données relationnelles. Ils permettent aux développeurs d'interagir avec les bases de données en utilisant le langage de programmation de leur choix, réduisant ainsi le besoin d'écrire des requêtes SQL brutes. Les bibliothèques ORM offrent une protection intégrée contre les attaques par injection SQL.

Former les développeurs et les équipes informatiques aux pratiques de codage sécurisées. Assurez-vous d’effectuer régulièrement des audits de sécurité et des tests d’intrusion pour détecter les vulnérabilités.

Appliquer le principe du moindre privilège

Le principe du moindre privilège donne uniquement aux utilisateurs de la base de données l'autorisation minimale requise pour effectuer leur travail. Suivre ce principe réduit l’impact des attaques potentielles par injection SQL, ou de toute cyberattaque, d’ailleurs. Appliquez également un contrôle d’accès strict à votre base de données.

Déployer un pare-feu d'application Web (WAF)

Un WAF surveille le trafic réseau entrant des applications et bloque le trafic malveillant potentiel sur la base d'une liste de signatures d'attaque bien connues.

Un WAF utilise des règles prédéfinies pour détecter les modèles suspects et les anomalies dans le trafic entrant, comme les mots-clés SQL et les charges utiles malveillantes. Il nettoie et valide les entrées des utilisateurs et bloque ou filtre les demandes nuisibles. Cela permet d'arrêter les requêtes SQL dangereuses lorsqu'elles entrent dans le système.

Les WAF modernes s'adaptent aux nouvelles méthodes d'attaque grâce à l'apprentissage automatique.

Protégez vos forteresses de données

Les attaques par injection SQL constituent une menace grave pour la sécurité des applications Web. Les entreprises risquent de perdre des données précieuses, la confidentialité des utilisateurs et leur bonne réputation si les attaques réussissent.

Bien qu'aucune solution unique ne garantisse une sécurité absolue contre l'injection SQL, la combinaison des mesures préventives dont nous avons parlé ici réduit considérablement les risques d'attaques. Les développeurs Web et les administrateurs de bases de données doivent employer des défenses strictes et renforcer leurs applications Web contre une exploitation potentielle.

Vous souhaitez une solution complète pour sécuriser votre site internet ? Découvrez les logiciels de sécurité Web et la manière dont ils contribuent à lutter contre les cyberattaques entraînant des violations de données.