Qu'est-ce qu'une injection SQL ?
Attaque par Injection SQL
L'injection SQL est une attaque qui manipule illégalement une base de données en injectant des instructions SQL (Structured Query Language) involontaires dans une application qui possède une base de données relationnelle (RDBMS). Il existe plusieurs types d'injection SQL en fonction de la méthode et de l'objectif, et du point de vue des cyberattaques, elles vont du vol d'informations à la falsification de données et à l'investigation des vulnérabilités. Bien qu'il s'agisse d'une ancienne attaque, elle cause encore beaucoup de dommages aujourd'hui, c'est donc l'une des attaques dont les organisations d'entreprise doivent particulièrement se méfier.
Bases de données relationnelles et SQL
Avant d'aborder l'explication de l'injection SQL, expliquons d'abord les bases de données relationnelles et SQL. Une base de données relationnelle est un type de base de données qui gère les données d'application sous forme de tableau. Il est utilisé dans de nombreuses applications métier en raison de la haute fiabilité des transactions (chaque processus individuel).
SQL est un langage (langage de base de données) pour l'exploitation de bases de données relationnelles. Les opérations sont largement divisées en trois catégories :
- Data Definition Language (DDL) pour la configuration de la base de données
- Data Manipulation Language (DML) pour la lecture et la mise à jour des données
- Data Control Language (DCL) pour différents contrôles tels que l’autorité
Les spécifications pour SQL sont stipulées par ISO. Par conséquent, s’il s’agit d’une base de données relationnelle, en principe, il est possible de l’exploiter de la même manière, même si le fournisseur est différent.
Exemple d'injection SQL
Un jour, un cyberattaquant découvre une application et en fait la cible d'une attaque. Nous supposons que le cybercriminel sait qu'un utilisateur légitime « Ken Sato » existe déjà sur cette application Web. Le cybercriminel tente de se connecter illégalement en se faisant passer pour l'utilisateur « Ken Sato ». Dans le formulaire de connexion, le cybercriminel entre dans la chaîne illustrée à la Figure 1. Lorsque l'application est vue du point de vue de l'application, l'instruction SQL illustrée à la Figure 2 est générée. Comment cette instruction SQL est-elle interprétée dans une base de données relationnelle ?
Figure 1 : Exemple d'intrants utilisés par les cybercriminels
Figure 2 : Énoncé SQL créé à partir de l'entrée de la Figure 1
Lorsque la base de données relationnelle reçoit cette instruction SQL, elle recherche d'abord une ligne dans la table UTILISATEURS où le NOM D'UTILISATEUR est « Queen Sato ». Étant donné que le nom d'utilisateur « Queen Sato » existe déjà, la base de données relationnelle passe à la condition de recherche suivante. C'est là que le problème commence.
Selon la condition de recherche, la base de données relationnelle recherche un utilisateur dont le nom d'utilisateur est « Queen Sato » et dont le mot de passe est « vierge » ou « '1' = '1' ». Étant donné que les mots de passe sont requis dans de nombreuses applications, supposons qu'aucun utilisateur avec un mot de passe « vierge » n'a été trouvé cette fois-ci. Mais qu'en est-il de « 1 » = 1 » ? Il s'agit d'une formule qui compare si « 1 » et « 1 » sont identiques. Naturellement, ce résultat est toujours vrai. Par conséquent, la base de données relationnelle reconnaît qu'un utilisateur existe, dont le NOM D'UTILISATEUR est « Queen Sato » et dont le MOT DE PASSE est « vierge » ou « 1 » = 1 ». Par conséquent, le serveur de base de données répond avec des informations associées au nom d'utilisateur « Queen Sato » au serveur d'applications sans vérifier le mot de passe pour ce nom d'utilisateur. Le serveur d'applications crée un écran de connexion réussie basé sur ces informations et les envoie en réponse au navigateur du cybercriminel.
Il s'agit du mécanisme de base de l'injection SQL. Nous avons donné une connexion à l'application Web à titre d'exemple facile à comprendre, mais les opérations de base de données utilisant des instructions SQL sont utilisées dans de nombreuses fonctions d'application. Par conséquent, cette attaque peut être réussie non seulement sur l'écran de connexion, mais également dans diverses situations de l'application.
Types d'attaques par injection SQL
Il existe plusieurs types d'injection SQL en fonction de l'objectif et de la méthode
Injection SQL basée sur les erreurs
Il s'agit d'une technique d'injection SQL utilisée pour explorer les configurations et vulnérabilités des applications. Une erreur est générée en saisissant intentionnellement une entrée non valide dans l'application, et les détails du système ciblé sont explorés en fonction du message d'erreur. Bien que la possibilité de falsifier ou de divulguer directement des données à l'aide de cette technique soit faible, les cyberattaques peuvent utiliser les informations obtenues à l'aide de cette technique pour lancer des attaques ciblant des vulnérabilités ou d'autres attaques d'injection SQL décrites ci-dessous.
Injection UNION
Il s'agit d'une technique d'injection SQL qui utilise l'opérateur UNION, un type de SQL, pour référencer des données arbitraires. L'opérateur UNION est un opérateur qui combine les résultats de plusieurs déclarations SELECT. Si un cyberattaquant ajoute une nouvelle déclaration SELECT commençant par l'opérateur UNION à une déclaration SELECT émise par une application, il devient possible pour l'application d'obtenir des données qui ne sont pas prévues par l'application. Si l'attaque réussit, le cybercriminel peut obtenir des données arbitraires au niveau de la table de la base de données. C’est pourquoi il s’agit d’une méthode qui peut causer des dommages particulièrement importants parmi les injections SQL.
Injection SQL aveugle
Il s'agit d'une technique d'injection SQL qui envoie une instruction SQL à une application et explore la structure de l'application en observant les différences de comportement plutôt que les résultats directs. Comme pour l'injection SQL basée sur les erreurs, la possibilité de falsifier ou de divulguer directement des données à l'aide de cette technique est faible, mais les cyberattaques peuvent utiliser les informations obtenues à l'aide de cette technique pour lancer des attaques ciblant des vulnérabilités ou d'autres attaques d'injection SQL.
Injection SQL de deuxième ordre
Il s'agit d'une technique d'injection SQL dans laquelle un cyberattaquant envoie une instruction SQL élaborée à une application qui est inefficace au moment de l'exécution, puis l'exécute plus tard. Cette technique étant exécutée dans un environnement où l'accès direct des utilisateurs n'est pas attendu, dans le pire des cas, elle peut entraîner des intrusions au niveau de la base de données, telles que des modifications des paramètres et des autorisations de la base de données.
Comment prévenir les attaques par injection SQL
Les applications actuelles sont composées de différents éléments. Par conséquent, des mesures appropriées pour chaque élément, en d'autres termes, une défense multicouche, sont nécessaires.
Voici les principales mesures pour éviter les dommages causés par l’injection SQL.
Mesures au niveau de la base de données
Une contre-mesure au niveau de la base de données consiste à optimiser les privilèges utilisateur sur la base de données. Comme mentionné ci-dessus, les opérations de base de données relationnelles sont largement divisées en trois catégories : Data Definition Language (DDL), qui configure la base de données ; Data Manipulation Language (DML), qui lit et met à jour les données ; et Data Control Language (DCL), qui gère divers contrôles tels que les privilèges. Cependant, dans de nombreux cas, les clauses DML telles que les clauses SELECT sont celles que la plupart des applications utilisent normalement. En limitant les privilèges pour d'autres opérations, il est possible d'empêcher la suppression involontaire des données et les modifications de paramètres.
Mesures au niveau des applications
Plusieurs contre-mesures sont disponibles au niveau de l'application.
Utilisation d'espaces réservés
Il est possible d'éviter l'injection SQL en créant des instructions SQL à l'aide d'espaces réservés. Les espaces réservés attribuent mécaniquement des valeurs d'entrée aux instructions SQL préparées à l'avance par l'application, et même si des valeurs non valides sont fournies comme entrée dans l'application, ce sont des valeurs non valides et la création de l'instruction SQL finale est interrompue
Échappement correct des valeurs d'entrée
Les symboles et chaînes de caractères qui ont des significations spéciales dans les instructions SQL sont échappés et traités comme des chaînes de caractères normales pour éviter les opérations de base de données relationnelles involontaires. Exemples de caractères pouvant être échappés : « » (citation unique) », « ; (semicolon/signification : le symbole en question est considéré comme la fin de l’instruction SQL) », « -- (deux tirets/signification consécutifs : le symbole après que le symbole est traité comme un commentaire) » et « UNION (clause/signification UNION : combine les résultats de deux ou plusieurs déclarations SELECT) ». En outre, dans le cas de chiffres tels que « 1 », il est nécessaire de définir explicitement s’ils sont traités comme des « chiffres » ou des « caractères » dans la base de données et de les convertir de manière appropriée.
Masquer les erreurs
Les messages d'erreur affichés par les applications peuvent fournir de nombreuses informations aux cybercriminels. Comme décrit dans « Injection SQL basée sur les erreurs », les attaquants peuvent utiliser ces messages pour lancer d'autres attaques. Lors du développement d'applications, il est important de ne pas afficher directement des messages d'erreur qui pourraient conduire à une compréhension de l'environnement interne du système, pas seulement de la base de données.
Application de programmes de correctifs aux systèmes de package
Si vous utilisez un système de package, nous vous recommandons d’appliquer le correctif officiellement fourni par le fournisseur dès que possible. Cela vous aidera à protéger votre système contre diverses vulnérabilités, y compris l'injection SQL.
Mesures au niveau du réseau
Les mesures au niveau du réseau comprennent l'utilisation d'IPS (système de prévention des intrusions) et de WAF (pare-feu d'application Web). IPS est une solution qui surveille le réseau et détecte/bloque les communications malveillantes. Le WAF est une solution qui protège les applications Web. En inspectant les communications Web, il détecte/bloque les attaques qui ciblent les vulnérabilités dans les applications Web.
Mesures au niveau de l'environnement d'exploitation global
Après la mise en œuvre des mesures susmentionnées, il est possible d’évaluer objectivement l’efficacité des mesures et de toute défaillance en effectuant des tests de pénétration externes et des évaluations de vulnérabilité.
Différence avec les scripts intersites
Bien que les deux vulnérabilités puissent être causées par un code malveillant ou des données envoyées par les utilisateurs et les administrateurs du site Web/de l’application, elles diffèrent en termes d’impact. CSS/XSS provoque généralement des perturbations côté client ou visiteur et peut être utilisé pour pirater des sessions, dégrader des sites Web, télécharger du contenu malveillant et rediriger des URL. D'autre part, les injections affectent gravement le côté serveur et peuvent entraîner une perte de données et d'autres conséquences.
Conclusion
Bien que l'injection SQL soit une ancienne attaque, il existe encore de nombreux cas confirmés de dommages importants au cours des dernières années. Par conséquent, il s'agit toujours d'une attaque dont les organisations doivent se méfier. Si une technique telle que l'injection UNION est utilisée et que l'attaque est réussie, elle peut entraîner une fuite d'informations à grande échelle. Cependant, en prenant les mesures appropriées, il est possible d'éviter ces dommages avant qu'ils ne se produisent. En tant que mesure de sécurité pour les organisations d’entreprise, en plus des mesures du point de vue de la défense en profondeur mentionnées ci-dessus, nous recommandons que des évaluations de sécurité soient régulièrement effectuées, telles que des tests de pénétration externes et un diagnostic de vulnérabilité.