Comment prévenir les attaques par injection SQL

Comment fonctionnent les attaques par injection SQL

Une attaque Structured Query Language injection (SQLi) est une attaque par injection de code qui permet à des acteurs malveillants de récupérer, de manipuler ou de détruire des informations sensibles contenues dans des bases de données SQL. Ces attaques consistent à insérer des commandes spécialisées dans les champs de requête SQL ; une fois exécutées, ces commandes peuvent permettre aux acteurs malveillants d'usurper l'identité d'utilisateurs légitimes, de consulter ou d'extraire des données protégées, voire d'obtenir un accès racine aux serveurs.

Souvent, l'acteur malveillant exécute l'attaque SQLi en exploitant les vulnérabilités des interfaces de programmation d'applications (API) qui ne différencient pas correctement le code légitime du code non fiable. Sans la possibilité de détecter les commandes ou les requêtes modifiées, ces API peuvent être utilisées pour exécuter des requêtes malveillantes ; par exemple, pour contourner les pare-feu d'applications web (WAF) ou les mesures d'authentification.

En règle générale, une attaque SQLi est exécutée selon l'une des trois méthodes suivantes :

1. L'injection SQL intrabande utilise un canal de communication unique pour lancer et finaliser une attaque. Parmi les types courants d'attaques SQLi intrabande figurent les attaques SQLi basées sur les erreurs (les messages d'erreur aident les acteurs malveillants à identifier des informations vitales concernant la base de données sous-jacente) et les attaques SQLi basées sur union (les acteurs malveillants utilisent les opérateurs SQL UNION pour dévoiler des vulnérabilités au sein de la base de données). Il s'agit de la forme la plus simple et la plus courante d'attaque SQLi.
2. L'injection SQL hors bande, en revanche, ne permet pas à l'acteur malveillant d'utiliser le même canal de communication pour lancer et finaliser une attaque. Au lieu de cela, l'application compromise doit être capable d'exfiltrer des données vers un point de terminaison distant contrôlé par l'acteur malveillant, souvent par le biais d'une requête DNS ou HTTP. Il s'agit de la forme d'attaque SQLi la plus complexe et la moins courante.
3. L'injection SQL inférentielle, également appelée attaque SQLi aveugle, nécessite que l'acteur malveillant transmette du contenu malveillant au serveur ciblé afin d'apprendre comment l'exploiter. Ces attaques revêtent généralement l'une des deux formes suivantes : l'attaque SQLi aveugle booléenne (les acteurs malveillants utilisent des requêtes de type vrai-faux pour forcer un serveur à produire des réponses différentes) ou l'attaque SQLi aveugle temporelle (les acteurs malveillants peuvent déduire les mêmes informations en examinant les variations des temps de réponse du serveur). Cette opération demande souvent plus de temps que le lancement d'une attaque SQLi intrabande, mais permet d'infliger des dommages comparables.

Pour consulter des exemples concrets de requêtes SQL bénignes et malveillantes, lisez Qu'est-ce qu'une attaque par injection SQL ?

Comment prévenir les attaques par injection SQL

Bien que les attaques par injection SQL (SQLi) constituent l'une des menaces les plus répandues pour les API, elles peuvent efficacement être évitées grâce à des stratégies de prévention adéquates. Parmi les approches utiles pour prévenir les attaques par injection SQL figurent la restriction des procédures de base de données, l'assainissement des entrées de base de données et l'application de l'accès selon le principe du moindre privilège.

Restreindre les procédures et le code de la base de données

Une attaque par injection SQL dépend en grande partie de la capacité d'un acteur malveillant à manipuler les entrées de données et les fonctions de la base de données. En restreignant ces entrées et en limitant le type de procédures de base de données pouvant être exécutées, les entreprises peuvent minimiser le risque de requêtes non autorisées ou malveillantes. Pour cela, elles peuvent opter pour les approches suivantes :

• Application d'instructions préparées et de requêtes paramétrées : les instructions préparées définissent le code SQL acceptable, puis définissent des paramètres spécifiques pour les requêtes entrantes. Toute instruction SQL malveillante est considérée comme une entrée de données non valide, et non comme une commande exécutable.
• Utilisation de procédures stockées : à l'instar des instructions préparées, les procédures stockées sont des instructions SQL préparées et réutilisables, qui peuvent être extraites d'une base de données. Elles empêchent des acteurs malveillants d'exécuter du code directement sur la base de données elle-même.

Valider et assainir les entrées de la base de données

Les entrées utilisateur dans une base de données SQL doivent être régulièrement contrôlées, validées et assainies, afin d'éliminer le code malveillant. La validation des entrées garantit que les données sont correctement inspectées et mises en forme, conformément aux critères prédéterminés, tandis que l'assainissement des entrées modifie (ou « assainit ») les entrées en supprimant les caractères non valides ou dangereux et en les reformatant si nécessaire. Les approches suivantes permettent d'assurer la validation des entrées :

• Établissement d'une liste d'autorisations : une liste d'autorisations peut aider à définir des entrées utilisateur valides, suivant lesquelles la base de données peut vérifier (et rejeter) les requêtes entrantes qui paraissent anormales. Par exemple, les caractères spéciaux et les URL étendues sont deux types d'entrées utilisateur qui peuvent être exploitées par des acteurs malveillants pour recueillir des informations sur une base de données (avant d'exécuter des requêtes malveillantes). Limiter l'utilisation de ces entrées peut contribuer à réduire la probabilité d'une attaque.
• Ajouter un préfixe d'échappement à l'entrée fournie par l'utilisateur : les entreprises peuvent également choisir d'ajouter un préfixe d'échappement à toutes les entrées fournies par l'utilisateur (c'est-à-dire les traiter comme une entrée, plutôt que comme une commande ou une instruction conditionnelle) ; ceci permet d'éviter que des caractères ou des mots spécifiques ne soient utilisés pour former des requêtes malveillantes.

Appliquer l'accès selon le principe du moindre privilège

L'accès selon le principe du moindre privilège est l'approche consistant à n'autoriser les utilisateurs à accéder aux ressources protégées que dans la mesure où leur rôle l'exige. Par exemple, il peut s'agir de limiter le nombre d'utilisateurs auxquels sont accordés des privilèges de niveau administrateur pour une base de données, ou même d'accorder aux utilisateurs un accès temporaire de niveau administrateur, qui pourra être ultérieurement révoqué.

Restreindre l'accès des utilisateurs en fonction de leur rôle permet également de minimiser l'impact d'une violation ; en effet, des acteurs malveillants qui utilisent des informations d'identification dérobées pour pénétrer dans une base de données seront également limités dans leur capacité à visualiser, modifier, voler ou détruire des données protégées. Pour la même raison, les entreprises devraient limiter l'accès partagé aux bases de données sur plusieurs sites web et applications.

Comment Cloudflare aide à prévenir les attaques par injection SQL

Cloudflare aide les entreprises à améliorer leur résilience face aux attaques SQLi grâce à un puissant portefeuille de solutions de sécurité des applications et des API :

• Le pare-feu WAF de Cloudflare surveille les logiques de trafic afin d'identifier d'éventuelles exploitations de code SQL, détecte les contournements et les variations dans les types d'attaques et utilise des technologies avancées, reposant sur l'apprentissage automatique, pour adapter les ensembles de règles du pare-feu WAF à l'évolution des méthodes d'attaque
• Cloudflare D1 est une base de données SQL serverless qui s'intègre nativement à Workers pour mettre en œuvre des instructions préparées et empêcher les utilisateurs de modifier ou de supprimer des bases de données