j'ai lu depuis le livre de recettes (sec. 4.2) p>
CakePHP vous protège déjà contre l'injection SQL si vous utilisez des méthodes ORM de CakePHP (telles que la recherche () et la sauvegarde ()) et la notation de tableau appropriée (c.-à-d. Array ('champ' => Valeur de $)) au lieu de SQL cru. Pour faciliter la désinfection contre XSS, il est généralement préférable de sauvegarder HTML RAW dans la base de données sans modification et de désinfectionner au moment de la sortie / de l'affichage. P> blockQuote>
Nous sommes donc sûrs que nous n'avons jamais besoin de désinfecter manuellement les données utilisateur contre SQL, à condition de limiter les méthodes telles que la recherche () et la sauvegarde ()? En particulier, est-ce vrai si je prends mes données de $ _Post directement au lieu de $ ceci-> données? En d'autres termes, supposons que je fasse une recherche () en utilisant $ ceci-> données. Ensuite, CakePHP assainir contre SQL lors de la rédaction du tableau $ Ceci-> Data ou lorsque vous écrivez la requête pour trouver ()? P>
Ma deuxième question concerne l'affichage de données désinfectantes. Est sanitize :: html idempotent? Donc, puis-je l'utiliser dans ma méthode Beforesave (), ou allez-y casser la deuxième fois que je sauvegarde Beacuse, elle est appliquée à nouveau et donne un nouveau résultat? P>
3 Réponses :
woah - si vous prenez vos données directement à partir de $ _Post que vous devez désinfecter absolument les données forte> si vous envisagez de publier les données sur toutes les pages à venir. Je me souviens d'il y a environ 2 ans une grande peur, car il a été révélé qu'une simple injection SQL permettrait à Cake 1.1 des sites à exploiter en raison de la disposition des requêtes sélectionnées utilisées pour se connecter. P>
Cependant, de nombreux utilisateurs ont intentionnellement utilisé l'ancienne règle pour les champs de saisie qui seraient utilisés dans SQL: P>
"Pour protéger contre l'injection SQL, l'entrée de l'utilisateur ne doit pas être directement intégrée aux instructions SQL. Au lieu de cela, l'entrée de l'utilisateur doit être échappée ....." P>
Donc, oui, c'était une question séparée, mais la même idée - bien que CakePHP soit patron, et qui nous a beaucoup pour nous, nous ne devrions jamais faire confiance à sa sécurité. L'impact de la performance des données de nettoyage vous-même est presque nulle. Alors faites-le. P>
Ok, je le fais, mais juste pour comprendre. Supposons que je fasse une recherche () en utilisant $ ceci-> données. Ensuite, CakePHP assainissez-vous contre SQL lors de l'écriture du tableau $ Ceci-> Data ou lorsque vous écrivez la requête pour $ ceci-> trouver ()? Dans le second cas, la désinfectante semble toujours superfleuse, même si j'utilise $ _post
En passant, je désigne des données qui seront affichées. Je demande que les données soient utilisées dans les requêtes SQL.
Non, cela ne vous affectera pas. Vous pouvez l'utiliser dans avant_save () code>. Vous aurez besoin d'une assainissement si vous utilisez une fonction de requête personnalisée I.E Fonctions où vous pouvez utiliser votre propre requête p>
À propos de cette question: P>
CakePHP assainissez contre SQL lors de l'écriture du tableau $ Ceci-> Données ou lorsque vous écrivez la requête pour trouver ()? P> blockQuote>
CakePHP ne désigne pas $ ceci-> Données dans le contrôleur, si vous vérifiez le code de gâteau, dans Dispatcher :: parsparams () http://api13.cakephp.org/view_source/dispatcher/#ource-244 Vous verrez que lorsque $ _Post est copié sur les données du contrôleur, les valeurs ne sont pas désinfectées. p>
Cependant, en utilisant $ _Post n'est pas recommandé car vous perdrez toute la magie du gâteau que vous gagnez lorsque vous utilisez le formulaire Helper P>