Protection des variables POST

Bonjour,

Je suis en train de réaliser un formulaire d'inscription, et je voudrais savoir quelle protection appliquer aux variables POST.
J'ai lu sur plusieurs forum des htmlentities, des addslashes, des htmlspecialchars,...

Le probleme, c'est que je ne sais pas si je m'y prend correctement :

1) J'applique un htmlentities sur toutes mes variables POST
2) Je traite mes variables
3) Quand tout est ok, j'applique un html_entity_decode pour l'affichage des données sur la page de récap.
4) addslashes pour un enregistrement dans mysql.

Et donc, je me pose forcement la question : j'en fais pas un peu trop, là ?

Si une âme charitable veut bien éclairer un débutant... (mais super motivé ! )

Merci

Tu peux aussi faire un "trim" sur tes variables et vérifier le type de la chaîne passée (ex. si c'est bien un int qui est passé pour l'âge).

Mais p-e le fais-tu déjà dans ton étape 2. ("Je traite mes variables")

Oui... dans la partie traitement.
Non, ce que je veux savoir, c'est si toutes ces étapes vous paraissent logiques, où alors si je surcharge pas inutilement...

Pour ma part ce sont les étapes que je fais habituellement et je ne crois pas qu'on doit les mettre de côté. Il ne faut pas faire confiance à l'utilisateur

Par contre dans la plupart des mes cas je fais un strip_tags, car je ne permet pas les balises html. Mais il est possible d'utiliser la fonction pour en permettre certaines et empêcher les autres, dépendamment de tes besoins.

Attention pour les balises autorisées dans strip_tags(), autant que je me souvienne ça n'empêche pas l'inclusion de javascript via onmouseover="" et cie.

Pour le reste, je pense que je changerais un truc ou deux:

1) htmlspecialchars() plutôt qu'htmlentities(), tout en m'assurant que le charset est bien défini dans un en-tête "Content-Type: text/html;charset=utf-8" (ou iso-8859-15, etc...). Mais htmlentities() ne devrait pas faire de mal, disons qu'il en fait plus que nécessaire à mon avis.

3) ça j'ai pas compris, ta page de récap n'est-elle pas en HTML ? auquel cas html_entity_decode() annule ton htmlentities() et s'il y avait des balises dans le texte elles redeviennent "actives" non ?

4) n'utilise pas addslashes() mais mysql_real_escape_string(). Addslashes() ne prévient pas toutes les attaques possibles sous MySQL, il faut utiliser la fonction qui est fait pour.

Merci pour vos infos. En ce qui concerne la page de récap, elle est bien en html, mais le problème avec htmlentities, c'est que lorsque l'internaute utilise les caractères spéciaux (é, â, etc...), l'affichage devient illisible.

Je cherche donc - en utilisant html_entity_decode() - un moyen d'afficher les caractères spéciaux comme les accents et autres.
Mais maintenant, c'est vrai que s'il y avait des balises dans le texte, elles devraient redevenir active... J'avais pas pensé à ça.

J'utiliserais bien htmlspecialchars() , mais est ce que cette protection est vraiment bonne ? Je veux dire, ne risque t on pas une injection sql ?
Ca fait pas longtemps que je code en php, mais j'ai toujours entendu dire qu'une des meilleurs protection, c'était htmlentities...

Quant à addslashes, j'avais pas vu ça comme une protection, mais plutôt comme une solution aux problèmes d'enregistrement des données, notemment celles qui ont un apostrophe (sans addslashes, je n'arrivais pas à faire une insertion en base).

Comme vous voyez, je débute... Mais c'est passionnant !!

htmlentites (ou specialchars) ne devrait pas être utilisé pour protégé des données POST, ça peut même parfois causer des problèmes.

Imagine que l'utilisateur peut entrer par exemple un pseudo de 8 caractères max. Si le mec tape ses 8 caractère, mais qu'il y a un "é" par exemple dedans, ça va donner plus de 8 caractères -> boom.

htmlspecialchars ne sert que lors de l'affichage final sur une page HTML. htmlentities servira si l'encoding risque de poser problème.

Maintenant y'a aucune protection spéciale pour $_POST qu'on peut appliquer de base, tout dépend de ce qu'on va faire des données :

* Affichage dans page web : htmlspecialchars
* Base de données : fonction de quotage du SGBD (genre mysql_real_escape_string). Ne jamais utiliser addslashes ou la directive magic_quotes_gpc, on peut rencontrer des problèmes suivant le charset
* Utilisation dans un header HTTP ou mail : suppression des retours chariots

- htmlspecialchars() est la fonction à utiliser dans 99,99% des cas.

Quand à la fonctin strip_tags(), elle présente un bug.

Et quel est-il? Parce qu'à chaque fois que je l'ai utilisé, tout fonctionnait correctement.

Eradwen a écrit :
Et quel est-il? Parce qu'à chaque fois que je l'ai utilisé, tout fonctionnait correctement.

Voilà un exemple :

<?php
$texte='Si je dois écrire dans mon texte une expression mathématique du genre 10<11, que va t\'il se passer avec strip_tags() ?';
echo strip_tags($texte);
?>

Bison a écrit :
Quand à la fonctin strip_tags(), elle présente un bug.

Si on se fie à la doc, ce n'est pas un bug mais bien son fonctionnement normal :

http://php.net/strip_tags a écrit :
Avertissement

Comme strip_tags() ne valide actuellement pas le HTML, les balises partielles ou rompues peuvent conduire à la suppression de plus de textes/données que désiré.

Eldebaran a écrit :
Si on se fie à la doc, ce n'est pas un bug mais bien son fonctionnement normal :

Merci de me citer la doc et merde, j'ai oublié "forme de" avant bug !

En présentant la chose sous "forme de bug" et en donnant un exemple concret, ça marque plus l'interlocuteur que de lui dire qu'en fait c'est le comportement normal de la fonction.

En plus ce n'est même pas une question de "BALISE" pas plus que de valider ou pas du HTML, strip_tags travaille sur le chevron d'ouverture.

Le seul caractère qui ne fait pas réagir le chevron ouvrant c'est un espace (caractère blanc)
Tout autre caractère, ça merde.
10<11 merde
10 < 11 fonctionne très bien

-10<-9 ne fonctionne plus
Modifié par Bison (08 Dec 2006 - 09:06)

Bison a écrit :
En présentant la chose sous "forme de bug" et en donnant un exemple concret, ça marque plus l'interlocuteur que de lui dire qu'en fait c'est le comportement normal de la fonction.

Oui.

De toute façon, je trouve le principe même de cette fonction assez dangereux. A mon avis, il faut vraiment bien savoir ce que l'on fait si l'on l'utilise...

Bonjour à tous,
Une question me chagrinne et si le n'est pas de réponse je vais passer un sale we lol

"[quote=FlorentG]htmlentites (ou specialchars) ne devrait pas être utilisé pour protégé des données POST, ça peut même parfois causer des problèmes.

Imagine que l'utilisateur peut entrer par exemple un pseudo de 8 caractères max. Si le mec tape ses 8 caractère, mais qu'il y a un "é" par exemple dedans, ça va donner plus de 8 caractères -> boom.

htmlspecialchars ne sert que lors de l'affichage final sur une page HTML. htmlentities servira si l'encoding risque de poser problème."

Si j'ai bien compris il ne faut pas utiliser htmlentites (ou specialchars)avant l'enregistrement des données saisie par l'utilisateur dans une base de donnée?

Je pensais que l'on pouvais faire un htmlentites (ou specialchars) puis un mysql_real_escape_string sur les variables POST (ou GET) avant l'enregistrement dans une BDD et puis nous n'avions plus besoin de nous occuper du format html dans la chaine saisie par l'utilisateur.

La méthode la plus propre serais donc d'appliquer un mysql_real_escape_string sur les variables POST (ou GET) avant l'enregistrement dans la BDD et lorsque l'on souhaite afficher les variables saisie par l'utilisateur sur une page au format html uniquement à ce moment la on utilise htmlentites (ou specialchars) pour l'affichage. Est ce bien cela la méthode la plus "propre"??

Merci pour votre confirmation et vos avis sur cette question d'ordre de traitement des chaines.

Michael