Comprendre l’injection SQL : stratégies pour sécuriser les applications web

L’injection SQL sévit auprès des développeurs web depuis sa première découverte il y a plus de 25 ans. Malgré son ancienneté, elle reste régulièrement l’une des principales vulnérabilités web, selon l’OWASP. Bien qu’elles soient faciles à prévenir, ces attaques simples comptent aussi parmi les plus lourdes de conséquences : elles mettent en péril l’intégrité des données de toute application web connectée à une base de données.

Qu’est-ce que l’injection SQL ?

Une attaque par injection SQL est une variante des attaques par injection qui permet à un attaquant de tromper une application web pour qu’elle transmette des commandes SQL directement à la base de données en son nom. L’attaquant peut ainsi injecter des requêtes SQL malveillantes par le biais des données saisies et obtenir le même niveau d’accès que l’application, ce qui lui permet d’interroger et de manipuler la base de données de l’intérieur.

Bien qu’il s’agisse d’attaques contre les applications web, les véritables cibles sont les bases de données qui alimentent le site. Toutes les données qu’elles contiennent risquent alors d’être divulguées, modifiées ou supprimées, compromettant ainsi la sécurité des données et les opérations.

Comment fonctionne l’injection SQL ?

Ces attaques exploitent les champs de saisie vulnérables des applications web. En général, une application web recueille les données saisies par l’utilisateur dans un formulaire. Celui-ci entre ses données puis clique sur un bouton pour que l’application les traite. Cela ne pose pas de problème pour les utilisateurs ordinaires, car les données fournies se limitent généralement à des lettres ou à des chiffres, que l’application sait analyser.

Le problème survient lorsqu’une validation insuffisante des entrées permet aux utilisateurs d’insérer des chaînes contenant des commandes SQL. Contrairement aux données ordinaires, les caractères spéciaux indiquent à l’application d’interrompre le traitement de la saisie habituelle et d’exécuter la commande ajoutée. Parfois, la requête obtenue s’affiche directement à l’écran, mais l’attaque peut aussi se dérouler en arrière-plan. On parle alors d’attaques par injection SQL à l’aveugle. Même si elles ne produisent pas toujours de réponse visible, leurs conséquences peuvent être importantes : elles peuvent modifier la base de données et permettre aux attaquants d’intensifier leur attaque.

Il est toutefois important de noter que les attaques ne ciblent pas uniquement les champs de formulaire. Tout moyen de saisie de données qui entraîne une interaction avec une base de données, comme les paramètres d’URL ou les appels directs à une API, peut être compromis de cette manière si des contrôles adéquats ne sont pas en place.

Exemples d’attaques par injection SQL

Les attaques par injection SQL sont simples à réaliser et font donc partie de l’arsenal habituel des attaquants.

Tout commence par une simple requête SQL côté serveur, comme celle ci-dessous.

SELECT * FROM products WHERE name LIKE '%$searchTerm%';

Dans cette requête, $searchTerm est remplacé par la saisie de l’utilisateur. En règle générale, si celui-ci saisit « phone », la requête exécutée par le serveur est la suivante :

SELECT * FROM products WHERE name LIKE '%phone%';

Elle renvoie tous les produits dont le nom contient le mot « phone ».

Voyons comment un attaquant pourrait exploiter cette requête par injection SQL. Supposons qu’il saisisse ‘; DROP TABLE products; –. La requête obtenue devient alors :

SELECT * FROM products WHERE name LIKE '%'; DROP TABLE products; --%'

Dans ce scénario, l’injection :

1. Termine la requête initiale : la partie ‘; ferme la condition de requête LIKE initiale.

2. Injecte une nouvelle requête : DROP TABLE products; est une nouvelle instruction SQL qui, si elle est exécutée, supprime toute la table des produits.

3. Met le reste en commentaire : – met le reste de la requête en commentaire, ce qui évite les erreurs de syntaxe dues à la partie restante de la requête initiale (%’;).

Résultat : l’attaquant peut supprimer le contenu de toute la table des produits et détruire ainsi toutes les données, sans disposer d’un accès légitime à la base de données. Ce n’est qu’une façon d’exploiter cette vulnérabilité. Des variantes plus élaborées peuvent s’appuyer sur cette méthode pour obtenir des privilèges plus élevés ou exfiltrer les données de la table.

Les dangers de l’injection SQL

Le risque le plus évident des attaques par injection SQL est la divulgation d’informations sensibles dans le navigateur. La plupart des applications limitent les données auxquelles un utilisateur peut accéder. Les attaques par injection SQL permettent de contourner ces contrôles et d’interroger la base de données comme le ferait l’application. Selon la nature des données sensibles divulguées, cette violation peut entraîner des sanctions juridiques et des pénalités pour non-conformité.

Cependant, ces attaques ne se limitent pas à la perte de données : les privilèges élevés qu’elles confèrent peuvent également servir à modifier ou à supprimer les données du serveur de base de données. Des attaquants ingénieux peuvent ainsi modifier les informations de la table des utilisateurs, notamment leur nom d’utilisateur et leur mot de passe. Ils peuvent alors se faire passer pour un utilisateur légitime de l’application disposant de privilèges plus élevés et mener leurs attaques sans déclencher d’alerte. Cette méthode peut aussi permettre de cibler les privilèges internes de la base de données afin de créer ou de modifier des utilisateurs et leurs autorisations, puis de se connecter directement à la base.

Comment prévenir les injections SQL

Les attaques par injection SQL représentent une menace durable pour la sécurité des applications web, car leur prévention exige une stratégie à plusieurs niveaux. Le premier niveau repose sur la validation et l’assainissement des données saisies : il s’agit d’éliminer les caractères susceptibles de sortir du contexte SQL ou de permettre d’autres attaques par injection. Le risque d’injection diminue considérablement lorsque toutes les données saisies par les utilisateurs sont minutieusement vérifiées et débarrassées de tout contenu potentiellement dangereux.

Cette approche peut être complétée par des requêtes paramétrées et des instructions préparées. Ces pratiques de codage sécurisé séparent efficacement la logique SQL des données saisies par les utilisateurs et neutralisent les risques associés aux requêtes générées dynamiquement.

Le dernier niveau consiste à effectuer régulièrement des audits et des tests de sécurité pour vérifier que les contrôles en place bloquent efficacement ces attaques. À l’aide d’outils automatisés, les organisations peuvent évaluer les vulnérabilités de leurs applications et repérer les points où les méthodes d’assainissement ne suffisent pas à prévenir ces attaques.

Bloquer les injections SQL de manière proactive avec Snyk

Le développement d’applications sécurisées exige des outils capables de détecter les vulnérabilités avec précision. Snyk API & Web se distingue dans ce domaine en détectant plus de 30 000 vulnérabilités potentielles, y compris des vulnérabilités critiques telles que le cross-site scripting (XSS) et les injections SQL.

Snyk API & Web est conçu pour détecter et traiter de manière proactive les problèmes de sécurité potentiels en s’intégrant parfaitement aux workflows de développement. Cette intégration simplifie le processus et propose des évaluations de sécurité automatisées et continues qui améliorent l’efficacité. En intégrant Snyk API & Web, les développeurs peuvent renforcer leurs applications à chaque étape du cycle de développement et veiller à ce qu’elles protègent efficacement les données les plus confidentielles de leur organisation.

Découvrez comment Snyk API & Web peut vous aider à sécuriser vos applications en réservant une démonstration en direct.

FAQ

Quel est le rôle d’un pare-feu applicatif (WAF) dans la prévention des injections SQL ?

Un WAF aide à surveiller et à filtrer les tentatives d’injection SQL, en ajoutant une couche de sécurité pour les applications web.

Les injections SQL peuvent-elles affecter les bases de données NoSQL ?

Même si la syntaxe diffère, les bases de données NoSQL peuvent également être vulnérables aux attaques par injection, notamment lorsque les entrées sont mal assainies.

L’injection SQL représente-t-elle un risque uniquement pour les sites web avec une page de connexion ?

Non. Toute partie d’un site web qui interagit avec une base de données, et pas seulement les pages de connexion, peut être vulnérable à une injection SQL.