Combattre l’injection SQL
Publié le 17 January 2008, par Babozor dans la catégorie Développement, Gestion de projet
Quoi? Mais keskecé que l’injection SQL?
Pour ceux qui ne le sauraient pas, l’injection SQL pour une application web est un équivalent à la grippe, un truc pas cool, qui fait bobo et qu’on pourrait simplement éviter (comme en se vaccinant par exemple, alors que le violent hacking brut-force pourrait trouver son analogie dans un bon vieux cancer du colon)…
L’injection SQL est le fait de rajouter un bout de code dans un champs d’un formulaire, de sorte qu’il soit interpréter par le moteur de base de données… c’est pas très dur à faire et aujourd’hui 90% (au moins) des sites sont complètement démuni contre ce type d’attaque.
Quels sont les risques?
Vous pouvez perdre une partie ou la totalité de vos données (suivant les cas, ce qui est déjà pas mal, avouez le…) ou voir vos données modifiées (comme un utilisateur standard passé en administrateur par exemple).
Comment se protéger
Il y a plusieurs moyens, l’idéal étant d’en cumuler certains pour assurer une sécurité maximale
- utilisez un utilisateur spécifique, qui a des droits restreints et ne pourra pas vider ou supprimer votre table de la base de données (mais cela ne l’empêche pas d’avoir dans certains cas les droits en suppression sur les données)
- utilisez des préfixes pour vos tables, pour éviter que votre table d’utilisateurs ne s’appelle user ou users, en ajoutant un prefix par exemple my_users, le nom de la table est beaucoup moins évident et donc un peu plus sûr. (pensez aussi quand vous installez des applications OpenSource type WordPress de ne pas laisser le préfixe standard toujours pour plus de sécurité)
- vérifiez et échappez toutes les données provenant des utilisateurs, en utilisant par exemple la fonction bien pratique mysql_real_escape_string en PHP… ne laissez aucune donnée brute, vérifiez au besoin, via une expression régulière…
- activez les protections internes (comme magic_quotes_gpc pour le PHP)
- utilisez des procédures stockées, là plus de soucis (ou presque) puisque les données sont passées en paramètres à votre moteur de base de données et non plus une requête dynamique.
C’est un type d’attaque trop souvent sous-estimé mais qui peut être dévastateur (et dramatique) pour votre système d’information.
C’est d’autant plus dangereux que c’est une attaque de bas niveau, tout le monde ou presque peut tenter sa chance, donc beware!
Si vous avez d’autres conseils ou anecdotes, n’hésitez pas, les commentaires vous sont ouverts…
le 17 January 2008 à 17h48
teu teu teu…
ZEU solution : ne plus développer “from scratch”, mais utiliser un framework. La plupart de ces problématiques - et même toutes les autres injections (JS, par exemple) ont déjà été traitées, elles sont pourchassées par des armées de codeurs qui ont le clavier entre les dents. Profitons de l’intelligence collective. Si ton framework préféré ne dispose pas de ce genre d’outils, laisse-le tomber comme une grosse chaussette de rugbyman après trois heures d’entraînement.
Injection SQL, hein ?
http://xkcd.com/327/
le 17 January 2008 à 17h51
Les magic_quotes en PHP sont à oublier, c’était une fonctionnalité destinée à protéger les développeurs débutants, mais elle pose plus de problèmes qu’elle n’en résoud…
Le plus sûr (en PHP5) reste d’utiliser PDO et les paramètres liés -> http://fr.php.net/pdo
le 17 January 2008 à 18h58
+1 pour mysql_real_escape_string(), +1 pour oublier les magic_quotes.
Sinon bah la régle de base c’est en effet de toujours filtrer à fond les données que l’utilisateur peux passer à l’appli.
Pour les procédures stockées je connais pas encore
le 18 January 2008 à 12h42
+1 pour les framework + utilisateur spécifique + préfixe
La photo c’est de toi ? En tout cas c’est bien déjanté, j’aime bien !
le 18 January 2008 à 18h10
Bon à savoir aussi, mysql_query() ne passe qu’une seule requête au serveur.
C’est pas grand chose mais ça limite énormément le champ d’action d’un éventuel script mal protégé.
le 3 February 2008 à 01h24
d’ailleur en parlant de sql injection yen a une petite sur achetemoiuniphone.com
si tu fais
http://www.achetemoiuniphone.com/send.php?id=79%20and%201=1 on voit
chérie, achète moi un iphone…
Et je te fais un iGosse.
par contre si je fais
http://www.achetemoiuniphone.com/send.php?id=79%20and%201=0
, achète moi un iphone…
ce qui veut donc dire que l’on a bien injecter dans la requete AND 1=0 ou dans l’autre cas AND 1=1…
et pour bien montrer
http://www.achetemoiuniphone.com/send.php?id=-1%20union%20select%200,1,2,3,4/*
le 3 February 2008 à 10h03
@hm: owned… ou faites ce que je dis et pas ce que je fais…
damned!