Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour,
Jusqu'à maintenant, j'utilisais setFromArray() avec mes données passées par un formulaire afin de mettre à jour mes données en BD via un insert().
Seulement je viens de me rendre compte que ça pose un gros problème de sécurité : si le client se fait une page html à sa sauce en ajoutant des champs avec des noms qu'il 'devinerait' de la BD, il peux les mettre à jour sans problème!
Faut-il donc soit ne pas utiliser ce setFromArray(), et déclarer chacun des couples champ/valeur manuellement?
Soit faire un unset sur tous les champs 'sensibles' qu'il pourrait y avoir en BD?
Bref cette fonction setFromArray() ne m'a pas l'air si sécurisante que ça!
Hors ligne
En effet, c'est une très bonne remarque ! Pour ma part, je ne passe jamais par cette méthode car je déclare toujours des variables correspondants aux champs que je vais utiliser. De cette manière, je peux les faire apparaître dans un message de log. Par ailleurs, les informations en provenance de la page ne correspondent pas toujours à un seul insert() en base de données, car plusieurs tables peuvent parfois être impliquées dans la transaction.
Il serait intéressant de voir comment font les autres membres...
Hors ligne
En effet, setFromArray() a le désavantage de laisser apercevoir les noms des colonnes SQL.
Mais c'est au developpeur de faire attention à sa sécurité, il n'est pas interdit, ni impossible, de coder une couche au dessus de setFromArray() pour masquer les noms des colonnes.
Hors ligne
Je n'utilise pas setFromArray et utilise une variable différente pour chacun des champs de la BDD
Hors ligne
Je n'utilise pas setFromArray(), en fait je passe par une classe maison de verification de formulaire qui elle construit mon tableau d'insert et au passage réalise les contrôles et les filtres. Surtout qu'il arrive souvent que l'on insert pas toujours toutes les variables du formulaire (genre le verif password par exemple pour une inscription, ou certains champs hidden).
Hors ligne
Dans tous les cas, je n'utilise jamais les variables $_POST directement. En fait je pars de $_POST et je construis un tableau $form à partir des valeurs $_POST qui m'interressent en faisant passer tous les champs de $_POST soit par des Zend_Filter, soit par des Zend_Validate en vérifiant qu'il n'y a pas de blague.
Ensuite je balance mon $form dans un insert ou un update.
Mais effectivement c'est super important de ne jamais faire confiance à ce qu'on reçoit par POST ou GET (ou COOKIE)
Philippe
Hors ligne
Oui il est important de filtrer toutes les entrées. Je fonctionne pareil avec un filtrage systématique des entrées dans le bootstrap :
// Filtres les entrées Zend_registry::set('filterGet', new MonSite_Filter($_GET)); Zend_registry::set('filterPost', new MonSite_Filter($_POST)); Zend_registry::set('filterCookie', new MonSite_Filter($_COOKIE)); Zend_registry::set('filterRequest', new MonSite_Filter($_REQUEST));
Hors ligne
Yep, je suis d'ailleurs sur un tutoriel sur la sécurité qui va sortir d'ici peu.
Pour en revenir à notre problème, j'ai aussi crée une classe, avec setFromArray() (sisi), mais qui brouille le nom des champs, et ne sélectionne que les champs dont j'ai besoin ( et non les éventuelles injections de champs ).
Le CRUD est une opération très très basique en dev web, et je pense que l'équipe de dev de ZF va nous pondre (un jour) une classe Zend_Form ( ou autre ) qui sera capable de générer un formulaire de CRUD, lié à une Zend_Db_Table, pour du CRUD ( avec pourquoi pas vérifs cotés client+serveur )
C'est pas très dur à faire en soit, mais ca se réfléchit tout de même....
Hors ligne
Pages: 1