Reprise du message précédent :

Je suis pas parano c'est ce qui a été fait sous mes yeux  + il y a eu un article sous le site de nexen.  
"Tous les enregistrements"  et alors c'est que trois champs. Généralement il y a pas 36 000 comptes, il va pas faire tomber le serveur ou mysql va pas te cracher au visage pour ça.  
Alors ne conseiller à personne pour un gain gagner de <1% contre une sécurité qui garantie à 100% l'injection SQL, crier au loup pour ça et que le reste du code soit à dégueuler il faudra se remettre en question.  
 
Au final, c'est pas déconseillé mais un choix.

 
file le lien.

Berceker United > Je vois pas en quoi commencer une requette par "select *" est une protection contre les injection SQL.
 
C'est vrai que HPENHP est protégé par le fait que le magic_quote est activé, mais ca me semble tenir plus de la coincidence que d'une véritable volonté de protection. D'ailleur, il n'a rien écrit pour le cas où un jour ou l'autre son systéme soit utilisé avec le magic_quote de désactivé et à ce qu'il parait (même si je sais pas comment le provoquer) d'autres caractéres peuvent permettre une injection sql dans mysql malgré le magic_quote et c'est pour ça qu'il existe une fonction nomé "mysql_real_escape_string".
 
La protection à 100% on y est pas encore.
 
PS : certe peut petre <1% de gagné pour la requette en question, mais s'il fait des select * à chaque fois qu'un count(*) aurait suffit, ca finira par faire beaucoup de pourcentage de perdus.

http://www.directionphp.biz/a_la_une.php?mois=2005-10

non je proposais pas de faire un select * mais un select login, password, id apres ces enregistrements sont comparé en dehors du sql. Ceci est fait seulement pour l'identification pour le reste à lui de voir le niveau de sécurité des informations

Là, je suis d'accord avec Smaragdus. Certe, t'évite l'injection sql pour cette requette, mais tu peux pas t'imaginer le temps que tu vas perdre surtout si t'as le serveur sql sur un serveur diférent de celui de hébergant le site web. le temps de transferer toutes les données peut se révéler vraiment génant.
En plus, t'as éviter des problémes pour une requette, c'est bien, mais qu'en est il pour les autres? Si tu considéres que le seul moyen de protéger ta base c'est de rien mettre de dynamique dans tes requettes, tu perdras énormément de temps à faire des "select x,y,z" sans condition et à tout traiter en php et si tu considéres que t'es capable de protéger toutes tes requettes conte l'sql injection même en y mettant du contenu venant de l'extérieur alors pourquoi ne pas le faire aussi avec celle là.
 
Non, franchement, je vois pas l'intéret de ta méthode.
 
PS : En fait, le seul intéret qu'elle pourait avoir, c'est si le serveur hébergeant la base de donnée est saturé et que le site web à énormément de ressource libre. Il est alors possible de décharger le processeur du serveur de la base de donnée. Mais la puissance économisé pour une simple vérification de login est tellement dérisoire que c'est vraiment pas par cette requette que je commencerais à l'appliquer.

ok je comprend la logique mais vous faite les saintes ni touch pour quelques enregistrements alors que j'en suis sur que sur le reste des scripts il y a des requete de psychopate qui doit y trainer. mysql n'est pas un veau pour récupérer une centaine d'enregistrements à moin qu'il gere le compte banquaire de la poste. de plus c'est executé que pour l'identification donc une fois par session.  
Alors arrêter de crier au loup pour si peut d'enregistrements et 3 colonnes parce que là vous vous faite mal à la tête pour un gain vraiment mineur.

Le gain est peut être mineur, mais il faut quand même se demander si l'abscence de gain est utile.

Si vous me prouvez que le gain est significatif en terme de temps entre le deux methode je retire tout ce que j'ai dis, vu qu'il y aura clairement sous mes yeux les chiffres. Comme je pense que le gain est vraiment minime et quasi incalculable pour pour peux d'enregistrement. Je pense que ce qui dérange c'est la sensation de gâchi d'information c'est à dire que sur x informations il peut y avoir que 0 ou 1 correcte. ET ça je peux le comprendre que cela gene .
Au final (parce que c'est pas maintenant que chacun lachera son os )
lorsque nous rentrons dans la problématique de la sécurité il y a toujours une contrepartie en terme de performance materiel, financier, souplesse, ...  
Dans ce milieu il faut faire un choix. Ici nous avons montré qu'il y avait plusieurs possibilités. Une ou il y a quand même un risque "potentiel" l'autre une perte de gain "plus ou moin significatif" selon le nombre d'enregistrements à contrôler.

Mouai bon, la grosse usine à gaz parce qu'il parait qu'un gars connait la faille de mysql_real_escape de php 3.7 ...

Tu as lu l'article au moin ? http://www.directionphp.biz/a_la_une.php?mois=2005-10
Mais il vous faut quoi pour faire comprendre que le real_esacape n'est pas fiable à 100%. Que vous soyez victime, risque de mettre en cause votre façon de coder, votre amour propre ?
Avant de dire "grosse uzine à gaz" prouve par un test que c'est lourd parce que là ça n'argumente pas.

 
Remplir un tableau à 3 dimensions avec tout les utilisateur de la base ... bein c'est lourd.
 
Question argumentation, je ne demande qu'à voir comment passer outre  
 

Peux-tu aussi nous signaler les parties de l'article qui mettent en évidence un problème avec ça parce que je vois pas.

 
C'est toi qui l'a pas lu
 
Dans le cas du login/password, on ne peut pas contourner le real_escape_string, arrête de pipoter avec ta "requete magique" qui passe à travers tout. Tout ça parce que tu veux pas admettre que tu t'es gouré dans ton algo d'authentification  

 
Oui moi aussi, j'aimerais bien savoir où berceker a cru lire ça (j'ai lu en diago mais bon, y a rien qui confirme ses allegations, au contraire)
 
On attend toujours cette "requete magique" (qui doit marcher sur php 3.0 ou un truc du genre)

Je me disais bien que j'avais loupé un message quelque part. En fait, tout est parti d'une discution que je n'avais pas lu visiblement.
 
berceker united> Tu pourais m'expliquer a quoi ca sert de créer trois tableaux à partir du résultat d'une requette pour les parcourir ensuite et ne surement pas s'en reservir ensuite? Ne serait-il pas plus logique de faire la vérification directement sur le résultat de la requette?
En fait, tu parlais de "petit" gain de vitesse, mais ta méthode telle qu'elle est mise en oeuvre est une énorme perte de vitesse puisque demandant le parcours de l'intégralité de trois tableaux avec en prime 3n affectations (n étant le nombre d'inscrit) 100% inutile.
 
Tant qu'a mettre en oeuvre ta méthode, j'aurais fais un :

Le mot clé "break", c'est pour pas vérifier les 3000 compte si c'est le second qu'est le bon. Une fois qu'on a trouvé celui qui correspond, on sort.
 
Fait ainsi, ca sera déjà beaucoup plus rapide que ce que t'avais fait.
 
EDIT : Et un "break" à la place d'un "continue" vu qu'on veut sortir de la boucle et pas passer à l'occurence suivante.

certes, mais le break, ça ne fait que diviser par 2 le temps de recherche (en moyenne)
 
Il existe d'autres moyens pour sécuriser les données des requetes :  
* ne pas hésiter à virer tous les caractères suspects qui n'ont pas leur place : "% / \ ' ;" pour un login par exemple...
* faire une procédure stockée
* settype() pour forcer les types (quand c'est un entier)
* et enfin mysqli_stmt_execute qui permet de binder les param

Smaragdus > Je ne faisais que rebondir sur le script de "berceker united" afin de le rendre plus rapide même si je n'utiliserais jamais cette méthode pour faire ça.

J'avais bien compris que tu ne voulais pas défendre cette méthode affreuse
C'est clair que c'est à bannir
 
A propos d'injection SQL, si qqn a d'autres idées pour sécuriser, il serait bon de les réunir dans le topic. L'avenement du php/mysql a "démocratisé" l'injection SQL donc ça serait pas mal de faire ça pour les newb et aussi les experts, on n'est jamais à l'abris d'un oubli (merci les magic_quotes )

mysql_real_escape_string le fait pas déjà ?

tu veux dire quoi par là ?

ce qui est rarement le cas pour un login / mdp non ?

je la trouve pas sur nexen. Y a plein de fonctions qui comment par ça, tu peux préciser laquelle tu utilises stp ?
 
Merci    

Cette fonction ne fait qu'échaper les caractéres jugé dangeureux (ca rajoute un \ devant) là, il propose d'enlever les caractéres dangeureux de la chaine.

Certe, et pour d'autres requettes, c'est utile. En fait pour un nombre, le bouquin de certification de php de Zend considére que la meilleure solution, c'est carément de faire un " $var = 0+$var " en bref, de demander à php de ne garder que la partie numérique et de virer tout ce qui est texte

Il parle de ça : http://www.nexen.net/docs/php/anno [...] xecute.php

bah faire un procédure stockée dans la base c'est du SQL
 

 
faut lire la fin de ma phrase : "(pour un entier)"
 

www.php.net : c'est la seule source pour la doc PHP

 
C'est sur que c beaucoup plus élégant ... mais tout aussi inutile
A pinailler, j'aime pas les break et continue, ça fait un peu "goto", je proposerais un  
 

Pas vraiment non, les langages correctement pensés présentent une interface de query sur les DB qui se charge de la sécurisation des requêtes sans devoir se la taper 'à la main' (et devoir trouver laquelle des 15 fonctions différentes ayant le même rôle il faut utiliser)
 
Alors après on peut ne pas utiliser ces mécanismes et ouvrir des failles SQL injection dans ces divers langages bien sûr, mais ça n'a rien à voir avec PHP qui n'offre par défaut aucun moyen simple, clair, flagrant et efficace de sécuriser les données

masklinn > Ne pas mettre dans le même panier les langages objets et les langages procéduriels.
C'est sur avec les langages objets, on peut avoir facilement des fonctions qui portent le même nom pour des traitements différents a partir du moment où elles sont dans des classes différentes.
 
Mais je vois mal là même chôse avec un langage procéduriel : comment le langage va faire pour savoir quelle fonction appliquer s'il a le choix entre 15 fonctions dont le nom et les paramêtres sont identiques?
 
Ce n'est pourtant pas par ce qu'un langage est un langage procéduriel qu'il sera mal pensé pour autant.
 
PS : C'est quoi que t'apelles un "moyen simple, clair, flagrant et efficace de sécuriser les données "?

Langages procéduriels
C'est nouveau?

Je vois pas le rapport avec ce que je disais  

Exemple Python DB API 2.0:
 
Les communications avec la DB se font via un objet de type Cursor, créé via un objet Connection symbolisant une connection à une DB donnée.
 
Tout objet Cursor d'un module conforme DB API 2.0 est tenu de fournir 3 méthodes de query de DB:
 
.execute(query[, parameters])
.executemany(query, sequence_of_parameters)
.callproc(procname[, parameters])
 
Je ne vais pas m'étendre sur executemany (qui a simplement pour but d'exécuter une série de queries en en changeant les paramètres) ou sur callproc (appel d'une procédure stockée, en dehors du fait qu'on spécifie un nom de procédure et non une query brute ça fonctionne comme execute).
 
Donc Cursor.execute
 
Cette méthode est l'interface de query de base, elle dispose de 1..2 paramètres, avec n>=1. Le premier est une query devant être safe, le 2e est une séquence ou un mapping (hashmap) de paramètres "unsafe" (reçu de l'extérieur par exemple) de la query. Les paramètres sont automatiquement préparés et sécurisés par execute et injectés dans la query en utilisant une syntaxe de type sprintf.
 
En clair, balancer une query avec ça donne ça:

# username et passwd sont deux données reçues en post, donc unsafe
con = sqlite.connect("db.sqlite" ) # db sqlite pour l'exemple
cur = con.cursor()
cur.execute("SELECT * FROM users WHERE username='%s' AND password='%s'", (username, passwd))

et je sais que ma query est sécurisée et que j'ai pas à craindre d'injections SQL.
 
Après il y a encore plus simple si on utilise un ORM genre ActiveRecord.

  ibase_execute ?
   maxdb_execute alias maxdb_stmt_execute : OK
   mysqli_execute alias mysqli_stmt_execute : OK
   ociexecute ?
   oci_execute ?
   odbc_execute : OK
   ovrimos_execute : OK
   pdostatement::execute : OK
   pg_execute : OK
   pg_send_execute : OK
 
 
Ceux que j'ai noté OK sont ceux qui semblent faire ce que tu décris au vu de la documentation, (survolé manque de temps) par contre, la doc ne dit pas si ca sécurise les éléments ou pas. Certaines de ces bibliothéques suportent une syntaxe objet ce qui fait qu'on se retrouve vraiment avec une fonction nomé "execute".
 
Comme quoi php n'est pas si loin que ça de la "norme" dont tu parles et n'est donc pas si mal pensé que tu le dis.

Perso j'ai pris l'habitude d'utiliser adoDB sur tes mes devs en php.
On a exactement le genre de chose que décrit Masklinn mais en plus ça permet de changer de base de données sans difficultés.
Et la liste des bases supportées est appréciable: ySQL, PostgreSQL, Interbase, Firebird, Informix, Oracle, MS SQL, Foxpro, Access, ADO, Sybase, FrontBase, DB2, SAP DB, SQLite, Netezza, LDAP, and generic ODBC, ODBTP.
 
edit: evidement la condition sine qua none de la portabilité est dans la non-utilisation de sql spécifique à un SGBD.

Moi ce que j'en vois, c'est que t'es obligé de préparer ta query avec *_prepare, puis d'y binder tes paramètres avec *_bind_param, puis enfin tu peux exécuter ton truc avec *_execute (en lisant la doc de mysqli_stmt_execute)
 
Et c'est dispo en PHP5 uniquement, donc si t'as besoin d'une PHP4.x ...

Ouaip, s'l'un des ORM dispos en PHP (ya aussi Pear ou dbx de dispos, entre autres)
 
Mais je parlais de ce qui était dispo dans les packages "standards" (e.g. utilisés le plus courrament)

Quand on dénigre un langage, on le fait sur la derniére version pas sur une ancienne dépassé depuis presque deux ans.
Sinon, je pourais crier sur les toits que l'asp est de la merde en barre même pas foutus d'avoir de base 1/20éme des capacités de php. Mais voilà, ils ont sorti asp.net que je ne conais pas et du coup, je ne me permet pas de rabaisser l'asp.
Toi, tu dis que le php version 4 est de la merde alors que la 6 est déjà en cours de programmation (j'ai même trouvé une version windows compilé dans l'arborescence de développement) et que la 5 est stable depuis longtemps. Il serait temps que tu te remettes au gout du jour si tu veux paraitre sérieux en parlant de défauts de php.
 
PS : En php t'as les "_prepare", dans les langages objets, t'as des ".create" ou des "new" à faire avant le "execute". Lequel des deux demande le plus d'étapes?

Ca n'a aucun rapport

Je sais bien que je suis aller chercher loin. Toujours est il qu'on a pas plus d'étape à faire pour exécuter une requette.

Pour une requête unique peut être, maintenant regarde ce que ça donne quand t'en fais 4 ou 5
 
(différentes hein, pas 5 fois la même)