bonjour,
  je suis en train d'analyser (et de decortiquer) un projet opensource dont je fais le fork et sur la page de login je trouve ce code (extrait) :

 
et j'essaye d'explique au createur du projet qu'il y a potentiellement une faille par "sql injection". La theorie est là mais pas la pratique, il ne veux donc pas prendre le probleme au serieux.
 
c'est moi qui fume ou bien y'a vraiment un risque ? le simple fait d'utiliser les simple quot ' suffit t'il à se proteger ? avez vous une demo à me proposer,  
j'ai deja essayé de saisir dans le champ login ceci (donc la variable $login) prendrai cette valeur.

mais ca marche pas a cause des simples quot
 
PS : je fournit la page complet à ceux qui le desire, mais pas en public car avec on peut remonter au projet initiale ce qui n'est pas bon pour les sites deja en production.
 
Pierre

bon ok j'ai trouvé il faut saisir ceci :

 
si l'admin de "forum.hardware" considere qu'il faut ferme ce post y'a aucun probleme

Indique "résolu" dans le titre et tu n'auras rien à craindre.
 
Qqn qui ne prend pas au sérieux un risque d'injection SQL est qqn de pas sérieux...

Ca dépend. Si magic_quotes_gpc est à On, la variable login sera quottée... Maintenant si elle est à Off, effectivement il y a faille. On ou Off, suivant l'encoding de la base, pouet.

Donc là c'est effectivement n'importe quoi... On utilisera plutôt un truc du genre :

On peut encore mieux faire, style prepared statements ou autres trucs genre sprintf. Pareil pour la récupération d'un truc dans post, on peut pré-nettoyer le tableau entier en début d'application.

Mais là comme ça c'est clairement le code d'un débutant ou quelqu'un pas trop soucieux de ce qu'il fait

un p'ti article sympa au sujet de la secu open source :  
http://www.zdnet.fr/actualites/inf [...] or=EPR-100

Faire confiance à MagicQuote, c'est selon moi une connerie monumentale.
 
Et ce, pour deux trois raisons :
1/ MagicQuote remplace les ' par des \', ce qui n'est pas supporté par tous les SGBD, car c'est ANSI et non SQL.
2/ Si sur le serveur de DEV, on a la main pour activer MagicQuote, ce n'est pas forcément le cas pour un serveur de production. C'est d'autant plus vrai le jour où on doit changer d'hébergeur : on ne pense pas forcément à vérifier lorsqu'on souscrit à la nouvelle offre.
3/ Le jour où un gars intervient en maintenance et voit des risques d'injection, il y a de grandes chances pour qu'il tente de blinder la chose. En SQL, l'échappement de ', c'est '' (2x'). Ainsi, le gars va transformer ' en '', puis MagicQuote va re-transformer en \'\'. Ainsi, dans la base, on va avoir 2x'' écrit au lieu d'un seul.
 
Bref, MagicQuote = grosse daube à éviter.
 
+1 pour les prepared statement qui sont les seuls à être réellement efficaces contre les SQL Injection (en plus d'être plus rapides qu'une requête générée comme un sagouin).

Mrharry : oui c'est en effet ce genre de secu que j'ai mis en place, j'ai meme interdit l'espace
mais j'aime bien le "alnum" je n'utilise en generale que les codes d'expession reguliere.
Mais ca ne fonctionne bien que pour des champs simple, par pour des champs de saisie complexe tel qu'un message.
 
Merci
 
 
--
OpenDCF : outil de gestion en php Devis/Commandes/Factures : http://opendcf.1g6.biz

MagicBuzz : en effet magic quot j'aime pas bcp non plus, mais concernant la demo que je veux faire toute la sécu repose dessus. Je n'ai donc plus de faille direct à proposer à l'auteur de ce code....