Les attaques de type "SQL-injection"

De nombreuses attaques consistent à détourner un programme en lui fournissant des entrées inattendues. Les attaques dites par " SQL-injection " sont l'application de ce principe au domaine des programmes SQL. Une publication récente (cf. l'URL donnée en fin d'article) explore en profondeur ce principe d'attaque dans le cas d'une application Web basée sur le noyau de base de données SQL Server de Microsoft. Ce type de "ressources", ainsi que la multiplication des applications Web couplées à des bases de données, rend cette sorte d'attaque de plus en plus courante. Nous rappelons donc dans cet article le danger induit par ce type d'attaque et les précautions que doivent prendre les développeurs d'applications pour y faire face.

Attaques de type " SQL injection "

Le langage SQL est très couramment utilisé pour accéder aux bases de données. Le plus souvent, les requêtes envoyées à la base sont construites en fonction des données fournies par l'utilisateur. Ainsi dans un système de consultation d'un catalogue de produits, il sera très courant d'extraire de la base de données les informations intéressant l'utilisateur par un ordre SQL du type :

SELECT produit FROM catalogue WHERE categorie LIKE '&choix_utilisateur' ;

Dans cet exemple, "&choix_utilisateur" représente la catégorie de produits sélectionnée par l'utilisateur. Si l'utilisateur est libre de saisir n'importe quelle chaîne de caractères pour la catégorie de produits (et que le programme n'effectue aucun filtrage des données fournies par l'utilisateur), il peut alors "injecter" dans cette chaîne un ordre SQL valide.

Par exemple, s'il fournit la valeur " toto' ; DROP table catalogue; -- ", il insère l'ordre de détruire une table ("DROP table catalogue") dans la commande SQL qui sera exécutée.

Il s'agit là d'un exemple typique d'attaque dite par "SQL injection". 

Moyens de protection

Ce problème n'est pas spécifique à SQL, et des exemples d'attaques "par injection" existent dans d'autres contextes (par exemple dans le cas de l'invocation de commandes du système d'exploitation par un programme).

Le premier moyen de protection pour y faire face est d'effectuer systématiquement (dans les programmes) un contrôle des données fournies par l'utilisateur (ou plus généralement reçues de l'extérieur). La méthode la plus sure est de définir l'alphabet autorisé en entrée et de rejeter toute entrée non conforme à cet alphabet.

De façon plus générale, et dans l'hypothèse où le filtrage ainsi mis en place pourrait être contourné, il est également recommandé de concevoir l'application de façon à ce que les composants activés par l'utilisateur disposent du moins de privilèges possible. Dans le cas d'une application SQL par exemple, les requêtes déclenchées par l'utilisateur doivent s'exécuter sous un compte SQL ayant des droits minimum sur la base de données (typiquement la lecture d'un ensemble limité de tables). 

Pour plus d'information

• Article "Advanced SQL injection in SQL Server applications" de NGSSoftware : http://www.nextgenss.com/papers/advanced_sql_injection.pdf
• Article "How To Remove Meta-characters From User-Supplied Data In CGI Scripts" du CERT-CC : http://www.cert.org/tech_tips/cgi_metacharacters.html