une solution simple, mais radicale, consiste à ce que l’utilisateur avec lequel tu vas te connecter à la base mySQL (celui que tu utilises dans mysql_connect(…) ) n’ai QUE le droit de SELECT sur la base/table que tu utilises pour ton application …
l’analyse de requète comme le dit Sans-Nom est également une bonne solution :oui:
Trop compliqué pour moi ça http://geekattitude.celeonet.fr/smileys/03dro16.gif
Donc on va fermer les yeux sur ces petites injections que personne ne fera et on va dire que mon problème est résolu http://geekattitude.celeonet.fr/smileys/03dro20.gif
Merci de votre aide :jap:
Ok mais l’analyse de requête est un peu trop … complexe pour moi alors je retiendrai que la 1ere solution 
:ap:
Merci pour votre aide on peut classer l’affaire :jap:
On ne ferme jamais les yeux sur ce genre de problème. C’est de la folie pure et dure.
Je te conseille au moins de faire une simple analyse pour t’assurer que c’est du SELECT.
Ou plus simple : interdire à l’utilisateur qui se connectera de faire autre chose que des SELECT 
N’existe-t-il pas un moyen de limiter une requête à une seule action du type SELECT, UPDATE ou DELETE ?
Mais quand j’y pense, un bête AddSlashes ne suffit pas à éviter les injections?? Car il devient impossible de mettre un quote pour fermet la requete et lancer l’autre non?..
Reste à savoir si AddSlashes rajoute des slash devant / … 
?
Ce n’est pas addslashes qu’il faut utiliser; c’est mysql_real_escape_string, pg_escape_string, et ainsi de suite. addslashes ne permet de protéger les chaînes que du côté PHP, si tu t’aventures à utiliser eval.
Sinon, comme je l’ai dis, y a pas 26 solutions :
vérifier que le premier mot de la requête c’est SELECT. Ca t’empêche de faire des UNION (SELECT …) UNION (SELECT …) mais bon.
Parser la requête (protection optimale, tu en fais ce que tu veux ensuite:)). Sauf que c’est compliqué à faire.
Créer un utilisateur machin, qui aura que les droits (ou privilèges) SELECT sur les tables qu’il peut utiliser. C’est la protection optimale (pour peu que mySQL gère ça bien), et la plus simple à mettre en place.
Changer d’user je suis d’accord, mais faut à chaque fois se reconnecter a la base avec l’user qui a le droit au select et après se reconnecter avec l’autre user qui gère le site en cas d’enregistrements non… ?
Qu’est-ce qu’il dit?
(kékidi? en sms)
S’il change d’utilisateur suffit d’ouvrir une nouvelle connexion pour le dit utilisateur hein et comme il s’agit que de requête type SELECT, ça ne posera pas de problème au niveau transactionnel (les données seront peut-être pas trop à jour, mais bon…) et au pire, il peut faire une transaction.
Mais bref.
Je dis imagines un site ou tu fais un user qui a le droit à tout, et un user qu’au SELECT.
Tu fais ton script tranquil, avec ton user qui a tous les droits pour pouvoir modifier si nécessaire, et hop d’un coup tu dois passer une requete dite sensible, tu dois donc te reconnecter à la base de donnée avec l’user qui a le droti qu’au SELECT, une fois la requete passée, tu te reconnectes avec l’user qui a tosu les droits…
C’pas un peu long ??
Bah rien ne t’oblige à clore la connexion limitée. :neutre:
Tu débute en limité… puis si tu (ton script) te rends compte que tu as besoin d’exécuter une requête sensible :
Les connexions persistantes c’est pas fait pour les chiens sinon
Tu fais une connexion persistante exprès pour cet utilisateur, sans qu’il puisse faire autre chose que des SELECT (gaffe aux transactions, lock et autres conneries pouvant bloquer).
Bref, +1 Raynor
Hum… j’avais ommis cette méthode de connexion, j’ai resorti mes vieux tutos de php, j’avoue, c’est mieux comme ça, mais ça n’empeche pas les injections dans les SELECT, et avec un SELECT on peux choper les pass de tous les users enregistrés sur une base… si on en connait la structure !
Pas si tu interdis l’accès à la table des utilisateurs.
Je sais pas ce que notre ami veut en faire, mais bref, à la base permettre des requêtes comme ça c’est dangereux tant qu’il ne les parsera pas, quite à faire un pseudo langage, ou séparer/simplifier le problème.
C’est ce que j’ai dit un post au-dessus du tien : l’utilisateur ne pourra envoyer que des requêtes SELECT :paf:
+1 :o
Conseil Zend du jour : "Never trust the user" :super:
crougnagna> dans ce cas, tu es bon pour faire un parser SQL, ou en chercher un sur le net. Je crois que phpmyadmin en a un.
Have fun !
Ou crée un espace dédié à cette connerie, ou c’est “safe”
D’ailleurs, ça me fait penser que j’aurai le même genre de crasse pour Admintools. Autant je peux bloquer l’utilisation de PHP avec token_get_all() ou un coup de str_replace(), autant si l’utilisateur est un programmeur il a besoin de PHP et autant j’ai pas trop envie de reparser tout le fichier.
Sigh.
autant t’es dans la m*rde quoi :o :neutre: [:shy] :paf:
Pour ça que j’avais prévu que les programmeurs étaient de facto des admins parce qu’il y a trop de points d’entrée où ils peuvent toucher à la bdd, accéder au compte de BDD, etc
heu … je vais voir ce qu’est un parser et je te dis si ta méthode me convient :paf:
(pour info je fais du PHP depuis 1 mois :whistle: donc je suis dans la phase "je bricole et je vois ce que ça donne à la sortie" :paf: )
J’sais juste que via PHPMyAdmin je peux modifier les privilèges des utilisateurs de sorte que seul SELECT soit coché …
Crougnagna rookie du PHP
Dans ce cas utilise la second option, et fait attention à ce que tu autorise:)
