Introduction à SQL injection

mieux protéger une application internet

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
SQL injection est un problème majeur dans la sécurité des applications internet. Il est assez complexe et ne peut pas être traité dans un seul chapitre. C'est pourquoi on commencera une série d'articles consacrés à cette thématique.

Dans cette première partie on va se concentrer sur tous les aspects théoriques liés à SQL injection. Au tout début on présentera une des définitions de cette vulnérabilité. Ensuite on effectuera un voyage dans le temps. Il nous permettra d'aborder l'historique du problème. Dans la troisième partie on passera aux notions beaucoup plus techniques. Elle contiendra les différentes méthodes d'injection ainsi que les dangers que peut provoquer SQL injection.

Encore une histoire de filtrage
Dans le monde du web, où chacun peut accéder à votre application, le filtrage des données est un aspect essentiel pour être bien protégé. Dans le cas du SQL injection, cette règle s'applique également. Car, si l'on veut lui coller une définition, on peut dire que :

"SQL injection est une attaque possible grâce au mauvais filtrage des données et l'exécution des requêtes contenant des séquences de caractères incorrectes".

Pour illustrer cette définition laconique, on peut utiliser l'exemple avec le chargement d'une commande grâce à son identifiant numérique. Imaginons, qu'on veut accéder au résumé de la commande 1394. Pour faire cela, on doit passer ce numéro à travers un formulaire avec un input du type texte. Notre application web reçoit cette information, se connecte à la base de données et recherche dedans l'existence d'une commande correspondant au paramètre envoyé. Cependant, le programme attend strictement un seul type de données : un chiffre (integer). Et la passation d'un autre type, par exemple, d'une chaîne de caractères précédée par un apostrophe, provoquera quoi ? Oui, vous devinez bien que c'est à ce moment-là qu'une attaque SQL injection pourra s'effectuer.

Le retour dans le passé
On peut constater que SQL injection existe depuis le moment où l'on a connecté l'application web au serveur SQL. Les premiers articles à ce sujet datent des années 90. du siècle dernier. On peut par exemple se référer au document
écrit par un certain Rain Forest Puppy dans un e-zin consacré à la sécurité des applications web
. Au début de la partie consacrée aux bases de données, il écrit :

"J'ai travaillé avec WT sur le problème des bases de données. WT a fait pas mal de bonnes choses dans la direction de la sécurisation des serveurs de bases de données. Surtout pour MS SQL. Il a détecté une anomalie et donc a contacté Microsoft. La réponse était surprenante. Selon eux, il n'y avait pas de problèmes. Donc en suivant leur logique, si tu lis la suite, ne te prends pas la tête pour se protéger.

- QUEL EST LE PROBLEME ? Le serveur MS SQL permet l'exécution de plusieurs commandes.
- QU'EST-CE QUE CE SIGNIFIE ? Je peux faire quelque chose comme :
SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5

Exactement ça, et ça va marcher. Les deux SELECTs vont s'exécuter correctement et afficher les résultats."
(source : NT Web Technology Vulnerabilities)

Le phénomène a pris de l'ampleur avec la popularisation de l'internet et de accessibilité aux serveurs web. Et cette attaque s'est avérée très ravageuse. En 2002 Jeremiah Jacks a découvert que Guess.com était vulnérable à ces attaques. Il a pu facilement obtenir les données des 200 000 cartes de crédit. L'année suivante il a battu son record en récupérant les numéros des 500 000 cartes du site PetCo.com.

Le nombre des numéros volés augmentait chaque année. En 2005 la base de CardSystems Solutions a perdu les informations sur 40 millions de cartes de crédit ! Même le site web anglais du Microsoft et celui du MySQL n'ont pas été épargnés.

Les sources de l'attaque
Toutes les données qui interagissent avec votre base de données sont susceptible de faire les dégâts. Il s'agit aussi bien des sources évidentes (paramètres POST et GET) que des sources moins connues, comme les cookies ou les sessions. Il faut alors être très vigilant et définir la politique de sécurité et, surtout, les types des données qu'on accepte pour une variable donnée.

Les types des injections
On distingue 3 types des injections SQL :
1. Injection numérique
Dans SQL on questionne les champs numériques sans mettre les apostrophe autour de la valeur recherchée. On aura donc la requête suivante pour chercher la commande avec l'identifiant 3 :

SELECT * FROM orders WHERE id_order = 3;

Comme vous pouvez le deviner, à la place de 3 vous pouvez placer une chaîne de caractères qui, du coup, va être prise en compte et va retourner toutes les commandes. La requête avec ce code injecté se présente ainsi :

SELECT * FROM orders WHERE id_order = 3 OR 1 = 1;


2. Injection de la finition prématurée
Même les commentaires (qui dans SQL s'expriment par --, /* */, #) peuvent s'avérer dangereux. Prenons notre requête précédente en y rajoutant une condition supplémentaire. On va rechercher la 3e commande, réalisée par le client avec l'id 39 :

SELECT * FROM orders WHERE id_order = 3 AND customer_order = 39;

Grâce à l'injection des commentaires on peut provoquer que notre requête va s'exécuter seulement avec la première condition. La requête contaminée, la voici :

SELECT * FROM orders WHERE id_order = 3 -- AND customer_order = 39;


3. Injection d'une nouvelle requête
Le troisième type de l'injection consiste en l'exécution de plusieurs requêtes au lieu d'une. Toujours avec notre exemple, on va essayer d'injecter le code qui sélectionnera et, dans un deuxième temps, supprimera toutes les commandes.

SELECT * FROM orders WHERE id_order = 3 /* AND customer_order = */; DELETE FROM orders;

Bien sûr, cette attaque est plus difficile à établir car il faut connaître la structure de la base.

On a rapidement parcouru les notions de base des SQL injections. Dans les prochains articles on passera plus de temps à pratiquer les attaques. On va aussi s'occuper de la protection d'une application web contre SQL injection.

L'article écrit en rythme de:
Lorenz - Danse avec moi
Bartosz KONIECZNY 03-09-2011 19:14 sécurité des applications web
Un conseil Zend Framework

Comment faciliter le travail entre notre application et l'Ajax ?

L'un des moyens est l'utilisation du ContextSwitch. Il permet de définir le type de réponse renvoyé.