L’injection SQL (SQLi) constitue l’une des menaces de sécurité les plus graves pour les applications web modernes. Elle permet à des utilisateurs malveillants d’injecter du code malveillant dans une base de données afin d’accéder à des informations confidentielles, de modifier ou de supprimer des données, voire de prendre le contrôle de l’ensemble du système. Il est donc essentiel, pour sécuriser toute application web moderne, de comprendre le fonctionnement des attaques SQLi et de savoir comment les prévenir et d’en avoir conscience.
Qu’est-ce qu’une attaque par injection SQL ?
Une attaque par injection SQL est une injection de code malveillant qui exploite les vulnérabilités d’une application. Lorsqu’elle réussit, elle peut permettre aux cybercriminels de :
- Accéder à des données sensibles
- Effectuer des tâches d’administration sur la base de données
- Modifier les informations de la base de données
- Récupérer des fichiers du système
Dans certains cas, les attaquants peuvent même être en mesure d’exécuter des commandes sur le système d’exploitation sous-jacent de la base de données. Les administrateurs de bases de données doivent être conscients de ces menaces et prendre des mesures proactives pour protéger leurs applications contre ce type d’attaque.
Comment fonctionne une attaque SQLi ?
Les attaques SQLi consistent à injecter du code malveillant dans les requêtes en langage SQL (Structured Query Language) d’une application. Ces attaques sont rendues possibles lorsqu’un site web ou une application web ne valide pas correctement les entrées utilisateur avant leur traitement par le serveur. En exploitant des vulnérabilités spécifiques de l’application, les attaquants peuvent accéder à des parties sécurisées de la base de données ou modifier des données existantes.
L’impact d’une attaque SQLi
Les attaques SQLi réussies peuvent avoir de graves conséquences pour les organisations, quelle que soit leur taille. Les attaquants peuvent être en mesure de dérober des identifiants et d’accéder à des bases de données contenant des informations sensibles sur les clients, comme des numéros de carte bancaire, des numéros de sécurité sociale ou d’autres données personnelles. Ils peuvent également modifier ou supprimer des données existantes afin de perturber le service ou de manipuler des enregistrements à des fins financières. En outre, les attaquants peuvent utiliser ces attaques dans le cadre d’une campagne plus vaste de déplacement latéral au sein d’un réseau.
6 conseils d’experts pour limiter les attaques SQLi
L’Open Web Application Security Project (OWASP) présente les meilleurs conseils contre les attaques SQLi dans sa fiche de prévention des injections SQL. Les mesures de protection primaires et secondaires qu’il préconise — notamment l’utilisation d’instructions préparées et de procédures stockées, ainsi que la validation des entrées par liste d’autorisation — sont résumées ci-dessous.
Première mesure de protection : utiliser des instructions préparées (avec des requêtes paramétrées)
L’utilisation d’instructions préparées avec liaison de variables (également appelée requêtes paramétrées) doit constituer la première ligne de défense contre les injections SQL. Ce style de programmation permet aux développeurs de définir d’abord l’ensemble du code SQL, puis de transmettre chaque paramètre à la requête ultérieurement, afin que la base de données puisse différencier le code des données, quelles que soient les entrées fournies par l’utilisateur.
L’avantage des instructions préparées est qu’elles empêchent les attaquants de modifier l’intention d’une requête, même s’ils y insèrent des commandes SQL malveillantes. En outre, la structure d’écriture plus simple de ces requêtes les rend plus faciles à utiliser pour les développeurs que les requêtes dynamiques.
Deuxième mesure de protection : utiliser des procédures stockées correctement conçues
Les procédures stockées sont des fragments de code SQL stockés et exécutés dans la base de données, ce qui réduit la nécessité d’intégrer du code SQL dans la couche applicative. Elles peuvent également être configurées pour accepter les entrées utilisateur, ce qui réduit la charge liée à leur validation au sein de l’application.
L’utilisation de procédures stockées correctement conçues est un élément important à prendre en compte pour réduire les risques liés aux attaques SQLi. S’il est vrai que toutes les procédures stockées ne sont pas à l’abri d’une exploitation, le recours aux constructions de programmation standard des procédures stockées, qui paramétrent automatiquement toute instruction SQL, peut s’avérer très efficace pour se protéger contre les attaques potentielles.
L’utilisation d’instructions préparées et de procédures stockées conduit finalement au même résultat — une protection efficace contre les tentatives d’exploitation par SQLi — à condition que le développeur veille à la solidité de leur conception et de leur exécution.
Troisième mesure de protection : valider les entrées par liste d’autorisation
De nombreux éléments des requêtes SQL ne sont pas destinés à utiliser des variables liées, comme les noms de tables ou de colonnes et les indicateurs d’ordre de tri, par exemple l’ordre croissant (ASC) ou décroissant (DESC). Dans ces cas, la meilleure approche consiste à valider les entrées par rapport à une liste d’autorisation.
Si les valeurs des paramètres utilisateur servent à déterminer les noms de tables et de colonnes, ces paramètres doivent être comparés aux valeurs attendues ou autorisées afin de garantir qu’aucune entrée utilisateur non validée ne figure dans la requête.
La validation des entrées par liste d’autorisation peut grandement contribuer à prévenir les failles de sécurité dues à des entrées malveillantes. Toutefois, si possible, il est recommandé d’envisager une réécriture complète du code, car cela peut révéler une mauvaise conception du code.
Quatrième mesure de protection : échapper toutes les entrées fournies par l’utilisateur
L’échappement de toutes les entrées fournies par l’utilisateur est une technique à utiliser en dernier recours lorsque les trois premières mesures de protection décrites ci-dessus ne sont pas réalisables. Échapper les entrées utilisateur avant de les intégrer à une requête est certes efficace, mais sa mise en œuvre dépend souvent de la base de données et doit être effectuée avec prudence, car il est impossible de garantir une protection contre tous les types d’injection SQL dans toutes les situations. L’échappement des entrées utilisateur est généralement recommandé pour le code legacy lorsque la mise en œuvre d’une validation des entrées n’est pas rentable.
Cinquième mesure de protection supplémentaire : appliquer le principe du moindre privilège
Pour garantir la sécurité des environnements de données, les administrateurs doivent réduire au minimum les privilèges attribués à chaque compte de base de données. Il peut être pratique d’accorder à un utilisateur applicatif des accès d’administrateur de base de données (DBA) ou des droits de type administrateur, mais cette pratique risque de créer des points faibles dans le réseau.
Pour garantir que tous les droits d’accès sont adaptés et sécurisés, il est conseillé aux administrateurs de repartir des principes de base et de déterminer les accès nécessaires, plutôt que d’essayer de limiter les privilèges existants. Chaque compte ne devrait disposer que d’un accès en lecture à certaines tables, si nécessaire. Cela contribue à éviter une exposition inutile des données en cas de tentative d’attaque.
Plutôt que de donner accès à l’ensemble d’une table, si un compte n’a besoin que d’une partie précise de celle-ci, il vaut mieux créer une vue qui limite son accès et lui attribue des privilèges sur cette vue particulière. Pour garantir la sécurité des données, il est recommandé, chaque fois que possible, de ne pas accorder d’accès aux comptes disposant de capacités de « create » ou de « delete ».
Pour sécuriser la base de données, le service informatique devrait élaborer une politique imposant le recours aux procédures stockées tout en empêchant les comptes applicatifs d’exécuter directement des requêtes. En outre, ces comptes restreints ne devraient pouvoir exécuter que les procédures stockées nécessaires et ne devraient disposer d’aucun accès aux tables de la base de données.
Avec SQLi, les attaquants peuvent manipuler des valeurs de paramètres autorisées et accéder à des informations auxquelles ils ne pourraient normalement pas accéder, mais auxquelles l’application elle-même peut avoir accès. Par conséquent, réduire les privilèges accordés à vos applications peut diminuer considérablement les risques de tentatives d’accès non autorisées.
Sixième mesure de protection supplémentaire : effectuer une validation des entrées par liste d’autorisation comme mesure secondaire
La validation des entrées par liste d’autorisation empêche la propagation des attaques et constitue une couche de sécurité supplémentaire pour ceux qui utilisent régulièrement des bases de données SQL. Lorsqu’elle est mise en œuvre comme mesure secondaire, elle doit pouvoir détecter et empêcher l’injection d’entrées non autorisées avant leur transmission à la requête SQL.
La validation des entrées est essentielle pour garantir que seules des données valides sont introduites dans le flux de travail et réduire au minimum les risques de dysfonctionnement liés à la persistance de données malformées dans la base de données. Ce type de protection doit de préférence être appliqué dès que possible, dès la réception de données provenant d’une source externe. Les niveaux syntaxique et sémantique doivent tous deux être évalués pour garantir une plus grande précision.
Exemple d’injection SQL
Pour comprendre comment une attaque SQLi peut se produire, il peut être utile d’examiner un exemple. Prenons le scénario suivant.
Un attaquant tente d’obtenir un accès non autorisé à la base de données utilisée par une boutique en ligne. Il élabore une entrée malveillante qui est injectée dans une requête SQL non protégée, ce qui lui permet d’extraire les informations confidentielles stockées dans la base de données et de les modifier à sa guise.
Par exemple, imaginons que la requête SQL se présente ainsi :
SELECT * FROM users WHERE username = ‘$username’ AND password = ‘$password.’
L’attaquant élaborerait une entrée malveillante telle que celle-ci :
Nom d’utilisateur : 1′ or ‘1’ = ‘1
Mot de passe : 1′ or ‘1’ = ‘1
La requête SQL modifiée se présenterait alors ainsi :
SELECT * FROM Users WHERE Username=’1′ OR ‘1’ = ‘1’ AND Password=’1′ OR ‘1’ = ‘1’
Le pirate a effectivement injecté une condition OR dans le processus d’authentification. Pire encore, la condition‘1’ = ‘1’est toujours vraie ; cette requête SQL contournera donc systématiquement le processus d’authentification.
Cette requête SQL modifiée renverrait tous les enregistrements de la « Users »table, qu’un nom d’utilisateur et un mot de passe valides aient été fournis ou non. Il s’agit de l’une des méthodes les plus courantes utilisées par les attaquants pour accéder sans autorisation à des informations sensibles.
En utilisant des caractères comme « ; » pour ajouter une autre requête à la fin d’une requête existante et « – » pour commenter, et donc tronquer, une partie d’une requête existante, un pirate pourrait potentiellement supprimer des tables entières ou modifier les données qu’elles contiennent. Il pourrait même exécuter des commandes sur le système d’exploitation sous-jacent, prenant ainsi le contrôle de la machine et l’utilisant comme point de départ pour attaquer le reste du réseau.
Quel est l’objectif d’une attaque par injection SQL ?
Une attaque SQLi poursuit quatre objectifs principaux : compromettre la confidentialité et l’intégrité des données, dérober des données et, à terme, compromettre l’ensemble du réseau.
- Compromettre la confidentialité des données :Un attaquant peut utiliser une attaque SQLi pour accéder à des données confidentielles stockées dans une base de données, comme des informations de carte bancaire et des mots de passe.
- Compromettre l’intégrité des données :Un pirate peut manipuler ou supprimer sans autorisation des données stockées dans une base de données. Cela peut entraîner le vol d’informations sensibles, voire des attaques pardéni de service distribué (DDoS)contre des systèmes qui dépendent de l’intégrité des données de la base de données.
- Dérober des données :Le vol de données est l’un des objectifs les plus courants d’une attaque SQLi. Les attaquants peuvent utiliser ce type d’attaque pour dérober des identifiants de connexion et d’autres informations sensibles dans des bases de données.
- Compromettre l’ensemble du réseau :Une attaque SQLi peut donner aux pirates accès à d’autres parties d’un réseau en utilisant la base de données détournée comme point de départ. L’attaquant pourrait ensuite lancer d’autres attaques contre des systèmes ou des réseaux connectés au réseau.
En résumé : protéger les réseaux contre les attaques par injection SQL
L’injection SQL est l’une des menaces les plus courantes pour la sécurité des applications web et peut avoir de graves conséquences si elle n’est pas traitée. Pour se protéger contre ces attaques, les organisations doivent intégrer la validation des entrées et les requêtes paramétrées à leur stratégie de sécurité globale.
Il est également essentiel de veiller à ce que toutes les bases de données soient correctement configurées et régulièrement mises à jour avec les derniers correctifs. En mettant en œuvre des stratégies efficaces de réduction des risques liés aux attaques SQLi, les organisations peuvent réduire considérablement le risque de subir une compromission.
unpare-feu de nouvelle générationrobuste. Pour bénéficier de conseils d’experts en sécurité réseau, tournez-vous vers l’une desmeilleures entreprises de sécurité des réseaux d’entreprise.