quand j'stocke dans ma bdd ce que l'utilisateur a renseigné dans son formulaire c'est mieux si je mets htmlspecialchars non ?? pour éviter qu'il me chie dans la base quoi

La base de donnée ne contient que du texte et ne va pas traiter quoi que ce soit, tu veux mettre ton htmlspecialchars lorsque tu affiche les informations sur une page.

M'enfin, faudrais qqn d'autre pour confirmer

Salut, pour pas que tu te retrouves avec des failles de la taille d'un gouffre dans ton code, faut que tu mette le htmlspecialchars (ou du moins que tu échape les balises de code de n'importe quel moyen) au moment ou tu récupère la chaine de caractères.

Petit article sur les failles XSS : http://www.thegeekstuff.com/2012/02/xss-attack-examples/

En gros tu ne fais jamais confiance en ce que l'utilisateur t'envoie

Voila

Le htmlspecialchars se fait à l'affichage, pas à l'enregistrement.

On évite de dénaturer les données qu'on enregistre au maximum, c'est le meilleur moyen de se retrouver avec des incohérences ou avec des "est-ce que j'ai fait mon htmlspecialchars avant ou pas ? "

Euh nope, on m'a toujours dit de faire les verif sur les input avant l'enregistrement sur BDD.

La raison reste la même que dans ma réponse précédente !

Comme ça à l'affichage tu te dis juste, : "Si ça vient de ma base, c'est que c'est OK !".

Enfin bon j'suis pas spécialiste web non plus ^^

ah voilà j'me disais bien

ptn Childermass jvais me méfier maintenant il m'a conseillé sur l'autre topic là en sécurité en plus enfin apparemment t'avais raison password_hash > md5 = sha1

Sauf que là aussi j'ai raison, je l'affirme : l'échappement de caractères spéciaux c'est à l'affichage, pas à l'enregistrement (enregistrement en cache mis à part). Tu peux chercher partout sur internet tout le monde dira pareil.

Ouais, une explication ne serait pas de refus svp, car je sais plus où j'ai aussi péché l'idée qu'il faut entourer les $GET et $POST par htmlspecialchars

Une rapide recherche sur stackoverflow confirme le propos de Childermass.

Du coup, htmlspecialchars est aussi requis avec la syntaxe alternative de PHP ?

Si tu utilise la PDO et sa fonction prepare, en bindant les paramètres, ..., tu n'as pas besoin d'utiliser ce genre de chose avant la requête, la chaine est sécurisé par la préparation de la requête et ne permettra pas d'injection SQL il me semble.

Ok merci pour ta réponse. Je le fais déjà.

Donc si on résume, on peut utiliser htmlspecialchars() pour prévenir les injections SQL mais il est préférable d'utiliser le binding de paramètres.

Par contre, pourquoi on utilise aussi ze famous function pour l'affichage, alors que les données qui sont dans la base peuvent être considérées comme safe non ?

J'ai pas dû saisir un truc.

Je ne suis pas sûr à 100%, mais je pense que ça évite d'autre forme d'injection sur les pages.

En soit, avec le binding tu évite les injections SQL et tu protège le SQL.
Avec htmlspecialchars, tu fais gaffe à ce qui est affiché.

Enfaite j'imagine que si le gars stock "&" volontairement, on ne veux pas voir un "&" sur la page, mais bien "&" , du coup avec htmlspecialchars, l'affichage ferais un "&amp;" (ce qui dans le cas cité n'est pas dangeureux, mais pourrais le devenir si l'utilisateur commençait à te pondre un <script>alert("PWNED");</script> (faille XSS)).

edit: vu que JVC le fait "AVANT" visiblement histoire de dénaturer mon post ( un autre exemple du pourquoi c'est mal avant et mieux après quand on veux justement causer de ça ), voilà comment je l'avais écrit:
http://pastebin.com/zd153ZPH

edit2: 'fin j'ai un doute de comment JVC gère ça, vu que c'est conservé à l'édition comme je l'ai écrit, mais déjà filtrer d'une façon qui convertit mes caractères en texte brut mais sans les balises html...

Ok je crois que j'ai pigé, merci bien

Le 04 mai 2016 à 22:22:29 yuser a écrit :
Ok merci pour ta réponse. Je le fais déjà.

Donc si on résume, on peut utiliser htmlspecialchars() pour prévenir les injections SQL mais il est préférable d'utiliser le binding de paramètres.

Par contre, pourquoi on utilise aussi ze famous function pour l'affichage, alors que les données qui sont dans la base peuvent être considérées comme safe non ?

J'ai pas dû saisir un truc.

Non, htmlspecialchars n'a rien à voir avec les injections SQL

htmlspecialchars c'est pour se protéger des failles XSS, et ça s'utilise à l'affichage.

Pour se protéger des injections SQL on utilise basiquement les requêtes préparées.

Fais gaffe MrSky, ENT_QUOTES c'est juste un flag de htmlspecialchars, htmlspecialchars fait bien plus que du simple ENT_QUOTES.

Pour JVC j'ai envie de dire qu'on s'en fout de comment ils font, c'est pas une référence. Mais s'ils ont bien fait les choses on peut imaginer que ce qui est stocké en BDD n'est pas modifié, qu'il y a un système de cache des pages générées (avec les caractères HTML échappés) au niveau du reverse proxy et que quand on edit un message on bypasse ce cache et on l'invalide. Au niveau du rapport perfs/utilisabilité ce serait cohérent, mais c'est qu'une façon de faire.

Un autre intérêt évident à garder des données non-altérées en BDD est que la plupart des moteurs de templates (Twig, Smarty, Blade...) font l'échappement des entités HTML par défaut, ça fait partie de ce qu'on attend d'eux après tout. Si on fait l'échappement en amont on se retrouve avec un double échappement qui est fait parce qu'on avait pas à le faire avant...