Posté par Marotte ⛧ .
En réponse au journal Fin du monde en vue ?.
Évalué à 2.
Dernière modification le 15 septembre 2016 à 17:29.
points d'interrogation simples d'un prepared statement (et si tu attends une chaine comme paramètre bah t'es baisé, "; drop table" est bien une chaine valide)
C’est bien pour ça que j’ai parlé de vérifier les valeurs des variables...
Si j’ai envoyé la requête préparée 'UPDATE table SET truc=? WHERE id=?' et qu’ensuite j’envoie "'; drop table machin;" comme valeurs, si le SGBD ne contrôlait pas la tronche des paramètres qu’il passe à la requête préparée on se retrouverait bien à exécuter une truc (du genre) 'UPDATE table SET truc=''; drop table machin;' WHERE id=''; drop table machin;''
ton exemple c'est pas un prepared statement donc je vois pas le rapport avec le sujet des prepared statement :)
Je sais que ce n’est pas un prepared statement et qu’un prepared statement ne consiste pas simplement à répéter une requête avec des paramètres différents depuis le code applicatif.
Je ne dis pas qu’on peut reproduire l’ensemble des fonctionnalités des prepared statement côté applicatif (c’est faux, puisse qu’il s’agit d’abord d’une fonctionnalité du moteur SQL), donc que l’on pourrait s’en passer, je dis simplement que la fonctionnalité "je me protège des injections SQL" peut quant à elle tout à fait l’être... Néanmoins je n’y vois aucun avantage, effectivement...
[^] # Re: faudrait donner quelques explications.
Posté par Marotte ⛧ . En réponse au journal Fin du monde en vue ?. Évalué à 2. Dernière modification le 15 septembre 2016 à 17:29.
C’est bien pour ça que j’ai parlé de vérifier les valeurs des variables...
Si j’ai envoyé la requête préparée 'UPDATE table SET truc=? WHERE id=?' et qu’ensuite j’envoie "'; drop table machin;" comme valeurs, si le SGBD ne contrôlait pas la tronche des paramètres qu’il passe à la requête préparée on se retrouverait bien à exécuter une truc (du genre) 'UPDATE table SET truc=''; drop table machin;' WHERE id=''; drop table machin;''
Je sais que ce n’est pas un prepared statement et qu’un prepared statement ne consiste pas simplement à répéter une requête avec des paramètres différents depuis le code applicatif.
Je ne dis pas qu’on peut reproduire l’ensemble des fonctionnalités des prepared statement côté applicatif (c’est faux, puisse qu’il s’agit d’abord d’une fonctionnalité du moteur SQL), donc que l’on pourrait s’en passer, je dis simplement que la fonctionnalité "je me protège des injections SQL" peut quant à elle tout à fait l’être... Néanmoins je n’y vois aucun avantage, effectivement...