Hello !
 
J'ai entendu dire que l'utilisation de procédures stockées réduisait les risques d'SQL Injection.  
Je n'arrive pas vraiment à me représenter pourquoi   . Dans tous les cas, mes paramètres (i.e entrées utilisateur) sont envoyés à ma base et utilisés par celle-ci dans une requête...
 
Ou alors c'est au niveau de la procédure que ca se joue ?  

Les PS ne réduisent pas les risques de SQL Injection. Ou du moins, seulement en partie (ce qui se trouve dans la procédure est effectivement blindé), mais pas ce qui se trouve autour.
 
Il faut que tu passes par une requête paramétrée pour être correctement protégé contre le SQL Injection (et ceci ne nécessite pas forcément l'utilisation de PS)

C'est à dire ?
 

ben regarde de la doc sur le sql injection pour voir comment ça marche. tu verras que faire un "exec plop($a)" ne blinde rien du tout si par exemple $a contient :
 
'a');drop table commandes;--

Donc les proc. Stockées ne protègent pas de l'SQL injection !

si
 
car si "plop(:login as varchar)" contient la requête
 
select count(*) from users where login = :login
 
=> quelque soit le paramètre que tu passes, tu ne pourras pas baiser cette requête.
 
par contre rien n'empêche de faire l'injection dans la foulée de l'appel de la procédure. si ton site est bien écrit, tu ne peux pas avoir un comportement frauduleux, mais tu ne protèges pas ta base des attaques.
 
regarde de la doc, c'est trop long à expliquer.
 
en tout cas, les PS à elles-seules ne protègent pas complètement contre le sql injection. seules les requêtes paramétrées offrent une protection complète (et offrent des performances accrues, tout comme les ps)

tu confonds les procedeure stockées et les prepared statement
 
http://maximilian.developpez.com/m [...] tatements/

quand on parle de requête paramétrée, y'a plus de confusion.
 
effectivement, entre ps (abréviation française de "procédure stockée" ) et "ps" (abréviation anglophone de "prepared statement" ) y'a de quoi confusionner
 
d'où l'importance d'utiliser la même langue partout quand on parle d'un truc
 
si on parle de procédures stockées, alors on parle de requête paramétrée, et si on parle de prepared statement, alors on parle de stored procedure, et y'a plus de confusion possible

parceque si je fous du SQL dans login il ne sera pas interpreté lors de la requete, c'est ca ?

voilà

Ok je vois, mais alors je saisis pas trop la différence entre stored procedure et prepared statement dans la manière ou le code est executé  

 
ben y'en a un, c'est une procédure stockée que t'appelle depuis ta requête qui n'est pas paramétrée (donc qui accepte le sql injection), et dans l'autre cas c'est une requête paramétrée (donc qui n'accepte pas le sql injection) qui ne fait pas forcément appel à une procédure stockée

ohh, allright.
 
Les dénominations avaient eu raison de moi, mais c'est plus clair maintenant, merci
 
En réalité ce que j'appelais procédure stockée était une requête paramétrée, donc forcément

en fait, le terme anglais "prepared statement" porte vraiment à confusion, parcequ'une procédure stockée, une fonction, un trigger ou une vue sont aussi des prepared statement.
 
alors que "requête paramétrée", c'est sans appel : il s'agit d'une requête à laquelle tu passes des paramètres (plutôt que de les noyer dans le texte de la requête)

mmmm ceci dit en java un PreparedStatement est bien une requete compilée a laquelle on peut donner des valeurs aux paramètres.

J'ai pas dis que c'était pas le bon terme, j'ai dit que le terme portait à confusion