Discussion :

[Michel_57]

Salut à tous

Je programme en php et je fais souvent des formulaires qui vont ensuite donner lieu à des requètes sql. Je voudrais donc trouver le moyen pour sécuriser ma base de données contre les injections sql.

J'ai déjà cherché un peu partout sur le net, j'ai trouvé plein de petites choses mais au final, ca donne toujours lieu à des polémiques sur les forums et ça ne se termine pas de manière constructive avec une solution.

J'ai vu des choses sur magic_quotes_gpc, sur addslashes et stripslashes, sur htmlentities, sur real_escape_string etc ... mais au final, comment je fais pour éviter les injections sql ?

En gros, ça me simplifierai la vie de pouvoir mettre 2 fonctions que j'includerai quand j'en aurai besoin :
- l'une que j'apellerai pour modifier ma chaîne avant insertion dans la base de données
- et l'autre qui me rendrait ma chaîne comme au début après son extraction de la base de données

Ou sinon, quels sont les caractères indispensables, sans lesquels on ne peut pas faire d'injection sql ? Peut-être me suffit-il de bannir ce caractère de tous mes formulaires, et de ne pas faire de requète lorsque sa présence est détectée ?

Voilà je n'ai jamais hacké de base de données et donc je ne maîtrise pas trop dans ce domaine, si quelqu'un d'expérimenté peut me donner des tuyaux, ce serait vraiment sympa !

Merci !

[stephane eyskens]

Toutes les fonctions que tu as citées servent justement à "sécuriser" les données reçues.

En gros:

- magic_quotes_gpc est une directive PHP (php.ini) qui est généralement mise à "On", c'est à dire que certains caractères des données reçues seront échappés. Lorsque magic_quotes_gpc est à On, il ne faut plus faire de addlsahes

- addslashes permet justement d'échapper les caractères significatifs.
- htmlentities & htmlspecialchars permettent de convertir en entité HTML tous les caractères ayant une entité HTML correspondante.

De manière générale, j'essaye de m'arranger pour filter systématiquement les données que je reçois.

Pour toute injection SQL, il est nécessaire d'introduire des espaces (%20), si les données que tu reçois ne sont pas censées en contenir, tu peux déjà les bannir, ce qui au final limite grandement les possibilités de hacking.

Si tu travailles avec mysql, les possibilités de hacking sont moindres étant donné que l'api php ne permet pas d'exécuter des requêtes multiples en un seul appel.

Il est à noter que les injections SQL constituent un problème général non inhérent aux applications web.

Voilà deux trois trucs.

[Michel_57]

je ne comprends pas vraiment ce que tu veux dire avec les espaces

Si tu travailles avec mysql, les possibilités de hacking sont moindres étant donné que l'api php ne permet pas d'exécuter des requêtes multiples en un seul appel.

la je vois pas non plus, je viens de tester de faire 2 requètes en même temps dans phpmyadmin, il suffit de les séparer d'un point virgule et ça marche donc à priori ca marcherait tout autant si je fais un insert dans une base, provenant d'un champ input, on pourrait y mettre un point virgule pour finir le insert et mettre derrière la méchante requète genre drop table.



si je bannis le point virgule de tout ce qui passe dans mes champs input avant de les utiliser pour faire des requètes est-ce que ça suffirait ?
(le point virgule on s'en sert rarement sauf peut-être dans un textarea c'est un peu embêtant comme restriction)

[DiGiTAL_MiDWAY]

le point virgule passe dans phpmyadmin car il separe lui meme les requetes et les excute une par une. Avec mysql il est impossible d'en effectuer plusieures avec une seule comme l'a dit stephane.

Quant aux espaces ce qu'il veut dire c'est que generalement la plupart des champs des formulaires (comme par exemple le champ password ou user) demandent des informations en un seul mot donc sans espaces. Donc tu peux tout de suite faire un filtre : si une entrée contient un espace c'est surement pas le type de valeur qui etait attendu. Ainsi comme les injections necessitent des espaces, cela te permet de les eviter. Mais ce n'est pas une methode infaillible et en plus certaines informations peuvent contenir des espaces sans pour autant representer une menace (sujet de topic par ex).

Sinon tu as mysql_escape_string(str) pour filtrer les champs afin d'eviter toute injection.
Apres si tu veux eviter les attaques par cross site scripting il faut que tu utilise htmlentities.

Donc pour resumer le mieux c'est mysql_escape_string et en plus htmlentities au moment de l'affichage pour eviter les attaques CSS.

[Michel_57]

en fait j'utilise beaucoup les expressions régulières et je limite les caractères à des alphanumériques mais c'est une politique très restrictive j'aime pas ça du tout (et elle ne fonctionne plus sur des textarea)
le problème si j'utilise des trucs comme addslashes, ce qui est inséré dans la bdd sera plus long (avec le slash) et donc un caractère comme l'apostrophe comptera comme 2, c'est embêtant tout ça, surtout quand on a un champ varchar de taille 15 caractères, si on veut entrer des apostrophes on ne pourra plus mettre 15 caractères au total. de plus, si l'ajout de slashs fait que la chaine dépasse 15 caractères elle sera tronquée et insérée en partie seulement j'ai peur que ça cause encore d'autres bugs comme ça.
donc supposons que je veuille garder ma politique de restriction (vu que le reste je le comprends mais je ne sais pas m'en servir efficacement) quels sont les caractères, ou les jeux de caractères sans lesquels un hackeur de base de données mysql serait totalement désarmé ?
parce que je vois que des exemples d'injection avec un 'OR 1=1' mais pas d'autres sur le net, donc à première vue je suis tenté de croire que si j'interdis les caractères de comparaison = < et > je suis sauvé.
bref malgré vos explications je suis complètement perdu là ... faut-il faire une carrière de hackeur avant de pouvoir commencer à programmer des trucs sécurisés ?

je vous remercie de la patience dont vous faites preuve face à un perdu !

[Michel_57]

concrètement vous faites comment ? je peux voir un exemple dans le cas ou je ne veux pas tester la chaîne de caractères avec une expression régulière ?
(une chaîne qui à le droit de contenir n'importe quoi)