Reprise du message précédent :
Ce n'est pas "tu ne dois pas" c'est "ça ne sert à rien" c'est pas pareil...

L'inconvénient c'est que tu bases ta sécurité sur le type d'un champ et non sur le méchanisme de validation. Avec un prepared statement, s'il t'arrive de modifier le type de ton champs (passer d'un identifiant string à un identifiant entier, ton appel reste strictement le même, et ta validation également. Après, tu peux rajouter une couche au niveau PHP pour, par exemple, avant le lancement de n'importe quel scritpt, retirer toutes les variables globales et en refaire un set "safe", mais pas au cas par cas, c'est le meilleur moyen d'en oublié ou de laisser du code mort.

Et si tu utilisais un ORM ou des prepared statements tu ne te poserais même pas la question et cette "faille" n'existerait pas.  
 
En bonus, au vu des différences de runtime entre l'exécution de la fonction is_numeric et une requête en DB, c'est au mieux de la nano-optimisation totalement identique, autrement dit de la masturbation.

C'est pas que ça a des inconvénients, c'est que ça revient à mettre une attelle à une jambe de bois.
 
Mettre en place des mécanismes de "sécurisation" n'effectuant que des opérations partielles, en fonction du type de la donnée et dans la couche application (sans prendre en compte les drivers de la DB, dont c'est le rôle) c'est automatiquement s'exposer à des oublis en plus de devoir déployer plus d'efforts que nécessaire.
 
En utilisant des prepared statements ou un ORM on fait disparaître la question même, parce que toutes les données sont sécurisées par défaut et par design et que bypasser cette sécurité ne simplifie pas l'écriture du code et rend souvent celui-ci plus difficile à lire (voir mon exemple quelques posts plus haut).
 
Fondamentalement, on s'en tape de savoir si ça gène ou pas de mettre des guillements autour des types numériques, le seul fait de considérer ça comme une solution à un problème de sécurité indique qu'il y a un problème dans le raisonnement sous-tendant à la question, parce qu'un truc pareil ne devrait même pas avoir à entrer en ligne de compte.

Juste comme ça.
Peut-être, tout simplement, que Fabien programme depuis PHP3 et là, pas d'is_numeric, d'ailleurs, ça doit être pour ça que j'en mets aussi (des guillemets), j'ai pas dut apprendre sur le bon site.

mais je parle pas d'utiliser is_numeric, je me fous d'is_numeric, j'ai jamais conseillé d'utiliser is_numeric, ça sert à rien ce truc, arrêtez de vous concentrer là dessus

qui dit prepared statement dit mysql 4.1 avec un php compilé avec l'API MySQLi, ce qui est très très très loin d'être standard.
Donc ca ne sera pas la solution retenue pour une appli commerciale qui doit être déployée sur le plus de platformes possibles.

en dehors de ce que j'ai souligné, il n'y en a pas, mais ca ne protège de pas grand chose.
Il suffit d'avoir un serveur avec php_magic_quote à off, et de rentrer dans l'url pour WHERE a="$_GET['a']"
 
pouet.php?a=1" OR pouet="plop
 
et ton guillemet n'a servi a rien

Bah alors explique au lieu de pleurer parce qu'on ne comprend pas ce que tu dis.
 
T'utilise un framework qui te fait tout tout seul ?
 
L'utilisateur envoie une variable en GET, au hasard, vu le topic, affiche_topic.php?numero_du_topic=23663.
 
Tu récupères ça dans ton script PHP, tu fais quoi ?  
Okey, tu testes pas que c'est un numérique (cf ton post).
 
Donc tu l'insères dans ta requête bdd sans guillemet ?
 
Je sais pas, mais tu parles pas qu'à des ingénieurs, ici on est sur HFR prog, pas sur HFR ingénieur prog, donc, tu expliques, faut pas venir pleurer après.  

Chez moi, j'ai un principe simple, déjà critiqué sur HFR, mais c'est que toutes les données entrées par l'utilisateur passent quoiqu'il arrive par un mysql_real_escape_string.
Ca permet d'apprendre à les gérer quelquesoit leur destination future (aujourd'hui ici, demain ailleurs, etc.) sans avoir peur de la sécurité.

si t'utilises ca et des guillemets c'est imparable niveau sécurité

 
Au hasard je dirais qu'il préconiserait un bout de code tout au début qui dit quelque chose du genre :
 

if (is_numeric($GET["id"]))
  {
     $id = $GET["id"];
  }
else
  {
     envoyer_chier_utilisateur();
  }

 
Et que dans tout le reste du code il utilise $id et n'a plus du tout à se soucier de celui-ci, c'est une donnée vérifiée et validée dont il n'a rien à craindre, ceci en ayant fait un seul test.

Bah oui, mais Masklinn dit qu'il ne parle pas de is_numeric.    
Donc quoi ?
Masklinn ne sécurise rien parce que ça fait perdre en perf ?
Je plaisante bien sûr, je ne pense pas.

 
Il parle pas de is_numeric en particulier je pense, mais plutot du principe de "on valide a l'entrée, après on est peinard".
 
Bon il parle aussi des PDO/ORM/... mais soit c'est avec l'option moquette en cuir dans php soit c'est que dans les vrai langages

Non
 
Je préconise l'utilisation de prepared statements, c'est à dire un outil qui permet de ne pas avoir à sécuriser manuellement les variables à injecter dans une query mais qui le fait automatiquement, ce qui revient au même qu'utiliser les *_escape_string sans avoir à les appeler explicitement, donc sans risque de les oublier
 
Et à un encore plus haut niveau d'abstraction l'utilisation d'un ORM (Object Relational Mapping, un truc qui transforme les accès DB en des appels de fonctions sur des classes/objets) de qualité pour ne même pas avoir à écrire de SQL

quelqu'un pourrait m'expliquer pourquoi faire un test plutôt qu'un cast ?

Nan, enfin pas dans le cas précis

gagné

 
En ce qui concerne ce que j'ai écris, parceque j'écris aussi souvent du php que ce que j'ai la diarhée

 
 
nan mais ça reste assez courant mine de rien (à moins que tu sois pas le seul à faire khakha mou )
 
castez bourdel, propre et efficace, que demande le peuple ?

 
Si tu caste, tu peut détecter la non-validité de ce qu'a entré l'utilisateur ou alors tu te retrouve avec la valeur par défaut sans être avertit ?

Ouai okey, donc en gros les messages de Masklinn n'avait rien d'autre comme but que de nous rappeler que lui fesait du super Python et du Méga Ruby et que PHP strop d'la merde.
 
Okey, super, en plus ça fait vachement avancer le débat.
 
- Tu fais un is_numeric en PHP pour vérifier tes variables ?
 
 - Non moi j'suis un kid, je teste toutes mes variables sur un integer en assembleur qui subdivise le résultat par rapport à la probabilité de piratage de mon site que la CIA veut pour son intranet.

0x90 > explicite ta pensée..

 
Bha l'inconvénient d'un cast, c'est que si t'attends un entier et que l'user t'envoie "ours malin", tu va te retrouver avec 0 comme entier, sans savoir que l'user t'as envoyé du caca. Parfois t'as envie de savoir qu'il a fait n'importequoi pour avoir le plaisir de le gronder (ou pour pas lancer une requète avec un 0 qui pourrait foutre la pagaille ou t'embeter par la suite dans certains cas).

ouais, c'est plus du chipotage que de la sécu là, j'attends un entier non nul, moi je caste et basta

Si le gars 'ripe' sur son clavier, et donc il te fourni '1234pouet' à la place de 1234 tu le saura pas et donc tu pourra pas lui dire : 'eh, mec, j'crois que ta ripé sur ton clavier'
 
 
oui, ce message est une redite de celui de 0x90

Heuu à la base non, la dernière fois que j'avais parlé de ça on m'a dit "ouah t'es un gros naze trop pas à jour maintenant PHP a des prepared statements comme tout le monde et tout"
 
Et accessoirement je vois pas le rapport avec ta 2e phrase, dans la mesure où il est plus simple d'utiliser des prepared statements que le contraire, mais s'pas grave
 
Après si c'est mal de parler de techniques de sécurisation inter-langages, je peux recommencer à taper sur PHP hein, moi ça me gène pas plus que ça

oui enfin comme je l'ai dis un peu avant, les prépared statements c'est php 5 + extension mysqli, et c'est loin d'être encore un standard.

 
 
mais concrètement ça change quoi ? pour moi rien
 
à priori mister Joce l'utilise, en mettant 1prout dans la variable owntopic on a la liste normale

pourquoi extension sqli si c est avec mysql que je veux jouer moi ?
mais sinon l extension mysqli est dans le package php5 classique
(apres c est sur que c est galere de trouver un hebergeur avec php5 mais sur un projet qui necessite une telle prise de tete en general le portefeuille suit )
 
sinon l orm ca ressemble a une bete classe sql non ?
j ai juste reussi a trouver quelques lignes sur wikipedia quelqu un aurait un bon lien ?

quand tu devs un forum, tu installes le truc sur le max de plateforme possible, donc les prepared statement, tu les oublies

 
 
Dis moi joce, au tout tout départ, MD.net était ditribué open-source?
Ou alors tu l'avais créé pour PPC puis tu l'as ensuite mis à disposition en payant?
Ou alors tu as toujours fonctionné sur un système comme l'actuel?

Euh, perso, j'ai un serveur dédié sous Debian.
PHP5 n'est pas considéré comme assez stable pour faire parti de la "bande des privilégiés des dépots Debian", donc, ce n'est pas une question d'argent, mon serveur dédié me coute surement plus cher que beaucoup d'hébergement mutualisé, c'est juste que Debian n'en veut pas, donc je n'utilise pas.    

Au tout départ, le forum MD était fait en VBscript et le forum PPC tournait sur l'ordi personnel de Joce en arrière plan.    
 
Quoi spa vrai ?
 
Rho, j'suis déçu.  

nan je veux juste un forum pour les sites dont je suis l auteur donc 3 messages pour tester les fonctions et le bide du "no-user complex"
et comme je compte m heberger j aurais php5 et toute la smala c est pas un probleme
puis ca ne m attire pas tant que ca je prefere une solution php plus puissante
j utilise une class sql et les orm ca m a lair bien sympa
veu juste dla doc  

bah t es dans le cas "c est galere de trouver un hebergeur avec php5"  
sinon j ai lu qu on pouvait le faire en c si c est vraiment le probleme  
http://dev.mysql.com/doc/refman/5. [...] ments.html
valable depuis mysql4.1  

(/me retourne sur google en attendant une ame charitable)

(zut je sais pas effacer un message)

Euh non, suffit de mettre un depot "testing" et hop j'ai PHP5, mais je veux pas, c'est un choix, celui de suivre des maitres de la sécurité, stout.    

bah je sais pas je debute j utilisais easyphp et c est la premiere fois que j installe tout tout seul
c est quoi le probleme de php5 ?

A oui, ça, c'est clair, au niveau de la base, ça change rien.
 
(juste un exemple pour illuster mes propos d'avant tout de même)
Question : ton age
le mec répond : je t'emmerde
Si tu cast, ça fait 0, c'est pas terrible...(et tu ne le sais pas qu'il pas mis le bon age)
 
 

 
  Tu compile

Je crois que t'as pas bien compris.
Si vraiment je veux PHP5, je rajoute une ligne dans un fichier de configuration et hop, ça me l'installe.
Mais justement, je ne rajoute pas cette ligne, j'ai fait le choix de faire confiance à des gens dont la sécurité est le métier et eux n'ont pas encore jugé bon d'inclure PHP5, donc, je ne le fais pas.

ouais enfin prendre le module deb pour php/apache pour moi c'est la pire des choses à faire : t'as tous les modules possibles et imaginables activés, c'est l'horreur niveau mémoire et perfs

Les mecs dont la sécurité est le métier ce sont les gars d'OpenBSD, pas ceux de deb

Ca c'est juste un point de vue. L'autre point de vue, c'est d'installer le soft avec la machine qui va avec. Généralement, c'est pas pour le prix du matos qu'on se fait chier à savoir quelle est la version de php qui va avec.