Reprise du message précédent :

tu te met a coder un forum ?

je comprends pas comment les quotes protegent de l injection

 
C'est pas plutôt 5 minutes pour PhpBB ?

 
select [...] where id=$id
 
si id = 1 or 1=1
 
ca fait select [...] where id=1 or 1=1 (donc ca selectionne toutes les ligne a cause de la condition 1=1)
 
avec guillemet ca fait:
 
select [...] where id="1 or 1=1" (sa ne selectionne rien, car l'id n'est pas valide)

et maintenant je mets

bof, disons que c'est dans les cartons, mais bon, ça sert aussi à tester des trucs.

if(is_numeric($ton_id)) et hop fini les failles

c est ce que je fais mais je voulais voir la demonstration parce que justement tous les exemples d injections que j avais vus ressemblaient plutot a celui de kangol et ca m intriguait
de toute facon je mets toujours les quotes

bref j ai pas le niveau pour parler plus longtemps ici merci d avoir repondu fabien

/me continue a lire en silence  

oué, mais une deuxieme couche ne sécurité ne coute rien (au cas ou tu oublie de faire ce test a un endroit).

oué mais la tu peux mettre un addslashes ou htmlentities pour les guillemet.

Addslashes est dépréciée hein    
 
Et puis pas besoin de faire des tonnes de couches de sécurité : une seule efficace suffit amplement
Si c'est bien codé, il n'y a pas de raisons d'avoir à protéger les requêtes SQL vu que les vérifications seront faites en PHP

lol

quoi lol ?

lol

lol aussi
 
Parce que là t'es en train de dire que les programmeurs font exprés de mal codé et de creer de faille. Comment peut tu etre sur de bien coder ?
 
Plus tu as des couches de sécurité, et moins ils y a de chance d'avoir des failles.  
 
C'est un peu comme si tu disais que le policier n'a pas besoin de gilet par balle vu qu'il peut se proteger avec un pistolet et vice-cersa.
Vaut mieux être trop sécurisé que pas assez.
 

Ce que je voulais dire, c'est qu'un "simple" if (is_numeric(...)) suffit à protéger des injections sql de ce côté là............ non ?

 
 
je ne fais pas de forum, mais j'aurais plutôt tendance à faire un cast, simple, rapide et efficace (par contre forcément, pour les chaines faut protéger )
 
petite réflexion : la majeure partie des failles viennent du besoin de gérer les droits dans la même "interface" que celle des utilisateurs
 
y'aurait pas possibilité de sécuriser tout ça en déportant les droits admins / modo ailleurs ? (tout en essayant de garder un max de convivialité) voire même de mettre ça dans un soft client ?

Principe simple en sécurité: ne jamais se baser uniquement sur une couche supérieure pour faire les vérifications que l'on pourrait faire à un niveau inférieur.

oué mais l'erreur est humaine, il se peut qu'un jour t'oublie de faire ce test. Donc une couche supplementaire est utile.  

 
non, le policier n'a pas besoin de gilet pare-balle parce qu'il sait que personne n'a d'arme sur lui puisque tous ont été fouillé. Si toutes les variables venant de l'exterieure ont été contrôlées et verifiées, pourquoi rajouter une couche.
 
Si c'est necessaire de rajouter une couche, c'est que les contrôles ne sont pas efficaces et ne portent pas sur tout.

Ca y est, je viens de rajouter l'édition "en place" des messages en Ajax sur mon forum.

Bonjour, je sais pas si cette question a déjà été traité (mes recherches sont resté infructueuses).
 
Pour une application qui génère énormément d'enregistrements(genre 10k/jours) dans une même table par jour, il vaut mieux quoi (sachant que les enregistrement ne sont pas modifié):
*) 1 table pour tous les enregistrements
*) 1 table "MoisCourant" et chaque premier du mois backuper les données dans une tables "année_mois"
 
Je sais bien qu'en mettant un index sur la date des enregistrement on est pas censé avoir de perte de performance, mais je voulais savoir si dans la pratique c'était le cas.

et avant de fouiller, comment peut t'il etre sur qu'il n'est pas en danger ?    
 
et sinon, tu va pas fouiller tous les gens de la rue quand meme ...
 
Bon ben sinon, chacun sa definition de la sécurité, si toi ca te suffit, j'espere qu'un jour tu n'oubliera pas de faire le test (ou bien un collegue qui touche a ton code et qui ne pense pas a faire cette verification de variable. )
 
C'est un peu comme si tu voulais mettre en sécurité tes bijoux et que tu blinde toutes tes vitres et tes portes mais que tu ne mette pas tes bijoux dans un coffre ...
 
Si tu ne veux pas mettre plusieurs couche, autant proteger a la racine du probleme, c'est a dire les guillemets de la requete.
 
 

Donc toi tu ne vas pas tester tous les messages postés par tes membres ?  
 

Je préfère mettre une alarme sur les portes et fenêtres de ma maison plutôt que sur la porte blindée du coffre, ça évite aux voleurs qui ne trouveraient pas le coffre de partir avec l'argenterie

Comme en plus, ça ne coute rien de mettre des guillemets, pourquoi s'en priver...

si c'est bien codé tu utilises mysql_real_escape_string quand tu as des entrées non numéric et c'est suffisant. (et c'est un traitement au niveau SQL, pas PHP dans ce cas).

intval powa

Voui, mais là on parle d'un id donc forcément numérique

spa optimisé

si ca a un coût : MySQL converti à chaque fois la string rentrée dans le charset courant si tu mets des guillemets.

Exemple :
 
Si tu rentres :
 
SELECT "pouet";
 
MySQL l'interpretera en interne comme :
 
 select _latin1'pouet' (si ton jeu de caractère par defaut est _latin1)

Autant pour moi, comme phpMyAdmin rajoute des apostrophes, je ne pensais pas.

 
1/qu'est ce tu veux verifier dans un message? je ne verifie rien, je convertis juste les caracteres speciaux.
 
2/ tu te contredit, si t'as si confiance en tes alarmes, pourquoi avoir un coffre?

la sécurité a un cout
 

Ca protège rien du tout tes guillemets, ça n'a aucun intérêt, éliminer le problème à la racine c'est empêcher toute possibilité de fournir des valeurs dangeureuses à la DB, et ça ça veut dire utiliser au minimum des prepared statements qui gèrent ça tous seuls sans que tu puisses rien y faire (à moins que tu aies vraiment envie d'être con, mais ça c'est ton problème).
 
Eliminer le problème à la racine, ici, c'est tout simplement faire en sorte qu'il soit plus difficile qu'il y ait un problème que l'inverse.

C'est dommage tes insertions sont rapides (pas de transformation de données) mais tes affichages eux sont ralentis (nl2br, smilies & co)

 
Wais, repartons dans le débat \o/

Ses éditions sont également plus rapides, la structure générale de son "workflow" est plus intuitive et plus simple, c'est probablement "fast enough" (premature optimization is the root of all evil toussa) et si ça l'est pas, rien ne l'empêche de commencer à cacher des pages ou des fragments
 
Enfin comme ça avait été dit pendant le débat, sa DB est notablement plus petite (puisqu'il stocke directement du raw text/textile/bbcode au lieu de stocker du HTML), donc gain de perfs sur les récupérations de données (qui sont le bottleneck de la grande majorité des applications, et tout spécialement des blogs et forums)

 
Tu crois pas que t'abuses un peu ?  

J'arrive plus à trouver les versions francisées de certains termes
(sauf pour le "fast enough", c'est plus une citation qu'autre chose)

 
workflow -> flot de données
 
raw text -> texte brut/pur  (quoique There Ain't No Such Thing As Plain Text. )
bottleneck -> goulet