Reprise du message précédent :
Pour ça, toujours faire gaffe aux messages d'erreurs affichés par l'appli...

et là en l'occurence, un coup d'htmlentities te protège non ?
 
edit : mais en fait y a un truc que je comprends pas. Là tu fais exécuter du javascript sur ta propre machine, en quoi c'est une faille ? Comment tu pourrais baiser une autre personne que toi ? Comment est-ce intégrer par le serveur quoi ?
 
>Unix Code Execution
Vous avez des détails là dessus ?

Faut voir si html machin escape aussi les retour chariots  
 

Ca repose un peu sur du bol, effectivement En fait, faudrait faire comme ça :

• Le site repose sur les cookie pour identifier un gars, et ne fait pas plus de vérifications ou de trucs spéciaux
• Le gars se logge en administrateur sur son site, et fait des trucs
• Toi de ton côté, tu piges la faille, et t'envoi au mec l'url spécial en disant genre "y'a un truc louche sur ton site là, clique sur ce lien pour voir"
• Le gars clique (il est toujours loggé), et hop, le p'tit script récupère document.cookie (et ton le session id + le reste), et envoi tout ça chez toi
• Et hop, t'as plus qu'a te faire passer pour l'administrateur maintenant que t'as un session id qui va bien

C'est un peu de bol qu'il faut avoir, mais y'a moyen

oki merci ^^

Dans le pire des cas, à part faire planter le script ça ferait une faillle de sécu de pas échapper les retours chariots ? (ça les échappe pas, puisque nl2br(htmlentities($tavar)), ça met bien des <br /> à la place des retours chariots )

oki ^^
et le HTTP Response Splitting c'est le même principe ? c'est seulement en filant le lien a quelqu'un que tu le couillones ? (j'ai pas l'impression, puisque tu peux jouer sur le cache etc ...)

Ouais voilà, c'est un peu le même principe, au final, c'est aussi une faille de type XSS

et pour les retours chariots, en quoi ça peut être une faille de sécu pour toi ?

C'est justement ce qui permet de séparer les différents headers, et donc d'injecter ceux qu'on veut (genre du coup en modifiant un 302 redirect en 200 ok)

oki pour les headers.
 
je parlais des failles XSS javascript que vous aviez montré, là je voyais pas bien où était le problème.
merci pour toutes ces précisions.

Comment tu crois que j'ai corrigé la faille que tu m'as signalé hier en une seconde et demi ?

ça les échappe pas. Fais echo htmlentities("bla\r\nye\r\n" ); et regarde le code source, tu vois bien qu'il y a des retours à la ligne
(et sur la page tu ne vois pas les \r\n en plus)
 
Comme dit précédemment, pour les retours chariots faut y aller à coup de str_replace (mais les retours chariot posent problème seulement si tu inclues l'input dans un header, sinon on s'en tape. Parce que sinon la seule faille c'est si tu utilisais un nl2br dessus, auquel cas y aura plein de <br /> dans la page )

Non, moi quand Florent parlait des html escape machin, je croyais qu'il parlait de mres. Moi je parse tout ce qui rentre (ou presque, j'ai des vieux bout de scripts qui oublient comme l'a montré florentG hier soir) par un mres.
 
 
P.S.: mres=>Mysql real escape string.

non mais attends, mysql_real_escape_string faut l'utiliser uniquement pour utiliser l'input dans une requête mysql ...
En plus ça nécessite une connexion mysql pour le faire, ce qui implique de la démarrer même si tu en as pas besoin. Donc c'est nawak ^^
Comme son nom l'indique, c'est pour ... mysql Ca regarde l'encodage de ta base, les caractères spéciaux de ta base, tout ça tout ça, pour échapper ce qui va bien pour ta base
 
Pour afficher un input d'utilisateur dans une page html =>
htmlentities($tavar, ENT_QUOTES, 'UTF-8');
y a rien de tel ^^
 
Et comme dit en dessous, pour les header, un coup de str_replace. Va pas utiliser mysql_real_escape_string à tout va

Je parlais, pour un header location, de faire un str_replace, parce que htmlentities laisse les retours chariots intacts, ce qui peut poser problème

Bah non, c'est pas nawak, j'ai toujours une bdd d'ouverte de toutes façons, ne serais-ce que pour l'enregistrement des statistiques de visite.
 

Ouai, sauf que comme par hasard, ça corrige aussi les failles dans PHP.
 

Je m'en fous, ma base est ouverte, donc je fais un mres et ça me transcrit mon texte pour corriger toutes les failles MySQL et comme par hasard, ça correspond aux failles PHP.    
 
Après, bien sûr que j'utilise un htmlentities pour afficher les infos, je parle de la réception bien entendue avec mres, lorsque ça arrive dans ton script, pas de la sortie, parce que htmlentities n'a aucun effet sur les "entrées", à moins que tu enregistres bizarrement dans ta bdd.

ouais enfin, après ton input il est "corrompu", t'es obligé de faire un coup de stripslashes pour afficher l'input de l'utilisateur, sans avoir la garantie que ça correspondra aux caractères d'échappement de la base de données ... Donc au cas réafficher de la merde.
 
Je reste persuader que c'est également nase en terme de performance puisque :  
- à chaque appel de mysql_real_escape_string on va demander à la base qu'est-ce qu'il faut échapper.
- en utilisant bien les sessions, y a plein de pages où t'as aucunement besoin de connexions mysql (bon ça après tu fais ce que tu veux). Enfin imagine un jour que tu fasses une page sans connexion mysql requise, tu vas en rajouter une pour rien ...
ou imagine une page où tu fais une seule requête au tout début de la page, et plus aucune après, dans ce cas tu ferme la connexion avant la fin du script ...
en terme d'économie de nbre de connexions, on peut mieux faire
 
Limite c'est comme si t'activais une espèce de magic_quote, mais même pas adapté au PHP ... (c'est pas parce que ça marche avec ta base actuelle, dans cet encodage et cette config, que ça sera toujours le cas).
Je sais pas pour toi, mais moi perso le magic_quote je m'en sers pas ...
alors un magic_quote pas adapté, encore moins
 

par hasard, en effet ...
 
C'est un peu comme pour le xhtml, où on t'explique qu'il y a une sémantique, qu'il faut pas utiliser n'importe quoi n'importe où. Là c'est pareil. C'est pas fait pour ça c'est tout.
Imagine demain y a une nouvelle fonctionnalité de mysql, qui demande d'échapper un caractère qui ne l'était pas avant, pas corrigé par stripslashes, etc, etc

Sauf que même sans mres, tu devrais le faire, donc exemple mort. Essaye donc de faire un <input type="text" value="toto c'est le "meilleur" du monde" /> tu vas rigoler.
 

C'est ridicule le temps perdu à compter, je le sais, je l'ai compté.
 

Je n'imagine rien, je ne développe pas sur des probabilités mais sur du concret, c'est évident que sans connexion MySQL, je ne vais pas en pondre une juste pour ça, dans ce cas là, je serais créatif, j'improviserais.
 

ça marchera toujours sur ma config actuelle, je loue un dédié pour m'autoriser cette liberté. Quand aux magic quote, ils sont activés pas PHP et inactivés par Apache chez moi, ce n'est pas optimal, ça fait partie de mes "libertés".
 

J'imagine rien, imagine demain PHP6 sort et plus aucun de tes scripts n'est compatible. Imagine que demain ton htmlentities ne fonctionne plus sous PHP 6, imagine qu'en 2035, les datetimes dans ta bdd ne seront plus valable, tu vas réécrire tes scripts demain maintenant que tu sais qu'ils ne fonctionneront plus en 2035 ?
 
Enfin voilà quoi, je donne ma méthode, une fois de plus on est pas d'accord avec moi, tant pis, chacun ses choix, mais n'essayez pas de me décourager, ça ne sert à rien, quand je me permet de donner une de mes méthodes sur HFR, c'est qu'elle a fait ses preuves et qu'elle fonctionne bien pour moi, point, après, qu'on soit d'accord avec moi ou pas, arrêtez de trouver des trucs bidons pour me faire croire que ce n'est pas valable.

Et tu veux pas recoder une lib PHP histoire d'être sur de pas utiliser les outils adaptés à une tache ?
Je pensais que l'argument de la sémantique xhtml allait te parler et l'emporter

c'est toi qui rigole j'espère. Si je dois faire ce que tu décris, j'utilise les outils faits pour (tu ne veux pas comprendre que tu n'as aucune garantie que ton stripslashes annulera bien les échappements de mysql_real_escape_string) :  

Hop, aucun souci, même pas besoin de stripslashes.
Si jamais tu as peur de mettre des simples quote pour délimiter value, tu passe le paramètre ENT_QUOTES à htmlentities. Personnellement, j'utilise cette fonction :  

Le pire, c'est que même ça ça te garantit pas une sécurité absolue, mais déjà bien plus clair, réutilisable, et sécurisé pour un affichage html que mysql_real_escape_string.

Il est où le concret, à ne pas vouloir utiliser les outils dédiées à une tache, et à utiliser des solutions qui devront être bidouillées en fonction du contexte, pour "improviser" ?
 

y a ptet des raisons ?
Après tu as raison, chacun fait comme il veut.

Ok je viens de tout capter la discussion. C'est super pas bien d'utiliser mysql_real_escape_string pour tout filter !!!
 
Y'a 2 cas :

• Insertion dans une base

Là on utilise MRES, vu que c'est la meilleure méthode pour escaper pour Mysql, sachant que ça prend en compte aussi le charset

• Affichage sur la page

Là c'est plus du tout MRES qu'il faut utiliser, mais htmlspecialchars (avec le paramètre ENT_QUOTES si on affiche dans un attribut, et ENT_NOQUOTES si on affiche dans un élément normal
 
Notez donc qu'il faut toujours avoir des valeurs dans slash ni rien à la base, sinon on risque de faire foirer pas mal de trucs. Donc il faut toujours récupérer des trucs comme ça :

Il faut toujours des valeurs vierges dans tous les cas, qu'on escapera suivant les cas en temps réel, sinon choc nucléaire certain
 

Je n'utilise pas mres pour l'affichage.    
 
Je l'utilise pour toutes les entrées que peut faire le visiteur ou que peut "modifier" le visiteur (comme tu l'as fait pour redirect.php) après, que ça aille dans une bdd ou pas, peu m'importe et je désactive systématiquement les magic_quote via apache.

Ouais mais si tu fait un mres, et qu'après tu affiche, ça foire, non ?

j'ai une fonction basique qui me fait la totale pour l'affichage, stripslashes, htmlentities, nl2br, etc.    

okay okay okay okay C'est bien

Bah c'est bien et le fait de passer toutes les entrées utilisateurs par un mres même quand ça ne va pas dans une bdd, ça permet d'utiliser toujours la même routine quelquesoit la chose à afficher, entrée utilisateur direct ou récupération dans la bdd vu que les slashs sont toujours au même endroit.
Heureusement, car dans un script, on peut coder une partie qui va gérer l'affichage dont les données entrantes ne "regardent pas" le script d'affichage. Donc en passant par un mres quoiqu'il arrive, les données subiront le même traitement qu'elles soient entrée en direct par le visiteur ou récupérer dans une bdd.

sauf que ça sert strictement à kedalle de faire un "mres" si ça va pas dans une bdd ... le seul autre cas où ça t'as été utile, c'est pour la faille des headers, et un str_replace suffit.  
Et comme j'ai déjà dis 20 fois (après j'arrête), stripslahes n'est pas "l'inverse" de mres, enfin bon ...
 
edit : t'es en train de dire que tu fais un mres sur les données qui sortent de la bdd ??    

Non justement, je fais un mres sur toutes les données entrés par l'utilisateur, c'est clair pourtant non ?
 
L'affichage, c'est complètement autre chose.

non justement
tu m'as mis le doute avec

je me disais que effectivement, tu fais ce que tu veux avec tes input, mais là je comprenais pas bien

Oui, la routine qui affiche les données est la même que ce soit entrée par le visiteur ou récupérer d'une bdd, mais c'est pas un mres, c'est la fonction que j'ai décrite plus haut qui fait un stripslashes, htmlentities, nl2br, etc.
 
Par contre, du coup, je fais un mres sur toutes les données pouvant être entrée ou fournie par un visiteur, car même si je ne le rentre pas dans une bdd, j'utilise la même fonction de réaffichage.
 
Exemple :
j'ai un formulaire avec 2 champs post, pseudo, email, la page qui reçoit va directement faire un mres dessus et ensuite va tester leur validité, ça limite les failles par la suite si je rentre dans une bdd et ça limite les failles PHP (oui oui, PHP aussi peut avoir des failles).
Bien sûr, il faut une connexion bdd, mais en tant machine, ça ne prend que dalle, le mres a juste besoin d'une connexion mysql pour savoir quel codage "protéger", mais ça ne représente pas une requête en temps.

bah je reste complètement opposé à ta solution, mais comme on changera pas d'avis ni toi ni moi, et que de toute façon tu fais ce que tu veux ...
ce qui est sur (histoire qu'on reste en bon terme lol), c'est que c'est mieux que rien ! ^^

Au contraire, ça bouffe à mort, sans parler du risque d'attendre le nombre max de connexions authorisé

Je ne vois pas pourquoi tu "restes complètement opposé" à ma solution.
Que tu ne l'adoptes pas ou que tu ne la comprennes pas, à la limite, mais que tu sois opposé sachant qu'elle n'a aucun inconvénient et que des avantages, je pige pas.
 
Ha si, son seul inconvénient, c'est d'avoir une connexion mysql ouverte.
Enfin, rien que pour le compteur de visite, j'ai toujours une connexion ouverte sur mes pages de toutes façons.

Preuve que ça bouffe à mort ?
J'ai testé, ça bouffe que dalle.

Ca dépend ce que t'as testé : temps processeur, ou temps d'exécution totale du script

ça fait 20 fois que je te sors tous les inconvénients, alors que ça n'a aucun avantage :  
 
- stripslashes n'inversera pas mres en fonction de la config de la base
- tu bouffes une connection, et tu interroges la base pour avoir le charset etc, pour rien.
- ce n'est pas fait pour ça. Si un jour tu bosses en collaboration, tes collègues ils l'auront mauvaises de devoir utiliser mres ^^
 
Enfin relis mes posts quoi et donc OUI, je suis complètement opposé à ta solution ^^

Et pour ne pas parler dans le vide, testez donc ça :

 
Et là !!! Ho, miracle, 50000 mres prennent moins de temps que 50000 str_replace.

T'es borné toi.
Si t'as une connection d'ouverte, les données que les utilisateurs entrent, tu les récupèrent de toutes façons en début de script, tu peux fermer ta base juste après.

Tiens, un script foireux :

En l'appellant avec genre pouet.php?a=pouet&b=truc&c=machin&d=bidule&e=tagada&f=salut
 
On obtient :

hey molo, j'ai déjà dit que tu faisais ce que tu voulais, que c'était pas pire que de ne rien faire, et que j'étais opposé à ta solution (qui est clairement toute pourrie).
Donc viens pas me dire que je suis borné, alors que tu l'es tout autant, en voulant utiliser des outils qui ne sont pas faits pour ce que t'en fais. Pour moi la discussion était close, puisque comme je l'ai déjà dit, ni toi ni moi ne changeront d'avis. Donc n'en viens pas aux compliments hein
 
Enfin bref, fin du débat, continue ta méthode toute pourrie, np

qu'est-ce que vient faire htmlspecialshars là dedans.    
Je parle des entrées, pas des sorties.

Je viens de te prouver que c'était fiable, que ça allait plus vite mais elle est toute pourrie, oui oui, c'est ça.

Bof, chez moi c'est parfaitement kif-kif, et il ne faut pas tomber s'il vous plaît dans la premature optimization C'est pas un mres ou un str_replace qui fera la différence, surtout que c'est super-rare d'en avoir 50 000. Au max une vingtaine, et là la différence entre les deux est ultra-minime. Faut plutôt se concentrer dans un cas concret (donc avec 20 itérations), où on observera que la connexion supplémentaire fait pencher la balance vers str_replace

C'est pour faire un peu de traitement, genre pour un cas en situation réel. Et on voit que ce qui bouffe tout là-dedans, c'est la connexion... donc faut la dégager, vu qu'elle sert à rien