Qu'est-ce que ce hacker a essayé de faire..?

(reprise du message précédent)

Concretement oui, quand je dois remplir/éditer "à la chaine" plusieurs pages depuis l'interface d'admin. Plutot que d'ouvrir une page, modifier la valeur, valider, ouvrir la page suivante, ça me va plus vite d'ouvrir mes 15 tabs d'un coup et de modifier les valeurs à la chaine en passant d'un tab à l'autre avec ctrl+tab mais avec cette protection je me retrouvais bloqué...

Dans une autre mesure ça me générait le même genre de probleme quand je charge un second formulaire en Ajax par dessus un formulaire existant, la valeur de la session est modifiée et mon premier formulaire ne peut plus etre validé.

Il doit y avoir moyen de régler ça en prenant en compte le timestamp lors de la génération du hash et de garder plusieurs valeurs en parallelle mais j'ai laissé tombé et je fais plutot une whitelist des champs que j'accepte d'etre modifié

J'utilise déjà un timestamp concaténé au hash, et je n'accepte que si ce timestamp a été généré il y a entre 3 et 300 secondes (les 3 secondes ça évite le flood par exemple sur un formulaire de connexion).

Salut,

Pour ce qui est de la sécurité des interactions avec la DB, mieux vaut utiliser PDO et ses requêtes préparées... Plus besoin de se soucier d'échapper soi-même les chaînes, le driver gère tout cela pour nous. Et, cerise sur le gâteau, c'est plus rapide qu'en utilisant mysql_select & consorts.

Dans mes nouveaux scripts, j'utilise déjà PDO, mais pas les requêtes préparées.
De toute façon en php, les requêtes préparées n'ont aucun sens, car la vie d'un objet contenant une requête préparée se termine à la fin du script. Ca aurait un intérêt si elles étaient stockées de manière durable, ce qui n'est pas le cas (à preuve du contraire on ne peut pas les stocker en session étant donné que ce sont des objets qui dépendent de la connexion, qui est elle-même non stockable en session).

IL faut quand même avouer que PDO, c'est bien pratique. Encore plus quand on crée soi-même sa propre classe qui l'étend... C'est génial pour gérer les erreurs par exemple : connexion impossible ? paf on fait directement une redirection silencieuse vers une page d'erreur 503 sans rien avoir à rajouter dans le code principal. Désolé, je m'égare... mais pour certains c'est comme si c'était vendredÿ aujourd'hui (ce n'est toutefois pas mon cas)
Modifié par QuentinC (10 Jun 2009 - 17:20)

QuentinC a écrit :
De toute façon en php, les requêtes préparées n'ont aucun sens, car la vie d'un objet contenant une requête préparée se termine à la fin du script. Ca aurait un intérêt si elles étaient stockées de manière durable, ce qui n'est pas le cas (à preuve du contraire on ne peut pas les stocker en session étant donné que ce sont des objets qui dépendent de la connexion, qui est elle-même non stockable en session)

Pas d'accord. Tu peux effectuer plusieurs fois la même requête au cours du même script PHP, par exemple pour insérer plusieurs lignes dans une table. Et si tu veux garder en mémoire des opérations à effectuer par le SGBD de façon permantente, ce sont les procédures stockées que tu dois utiliser, et non les requêtes préparées...

Peut-être que je me gourge mais il me semble que Quentin opposait la notion d'objet PHP à celle de java (par exemple).

En tout cas il est grand temps que je regarde du côté de PDO.

a écrit :
Pas d'accord. Tu peux effectuer plusieurs fois la même requête au cours du même script PHP, par exemple pour insérer plusieurs lignes dans une table.

On peut combiner plusieurs insert en un seul, de même qu'on peut simuler un update multiple en utilisant replace into.
Donc effectuer plusieurs fois la même requête dans le même script est plutôt rare, sauf dans le cas un peu particulier des requêtes insolubles autrement qu'avec de la récursivité (je ne vois que cet exemple).

Par contre il faudra un jour que je me renseigne sur les procédures stockées, mais il me semblais que cette fonction était désactivé par la plupart des hébergeurs.

a écrit :
Peut-être que je me gourge mais il me semble que Quentin opposait la notion d'objet PHP à celle de java (par exemple).

Oui, exactement.
De même qu'il ne faut pas oublier que les objets en session sont en fait détruits et reconstruits à chaque chargement de page.
Dans le même genre d'idée, il faudra un jour qu'on m'explique l'intérêt des connexions permanentes dans leur définition actuelle (fonctions pmysql_connect et pfsockopen entres autres). J'ai longtemps cru qu'on pouvait ouvrir de façon permanente une connexion dépendante de la session, ce qui aurait ouvert des perspectives très intéressantes... mais en fait non, ces fonctions n'ont pas un comportement très rationnel et très pratique. On atteint les limites de php là. Bon bref, une fois de plus je m'égare, désolé... cette fois c'est à cause de l'insomnie.