Discussion :

[nasuu]

Je ne sais pas si ça vaux le coup de "limité" les caractères poster par un utilisateur (pour la sécurité et/ou la propreté). Si oui auriez-vous une fonction interesante (j'utilise le latin1) ?

L'idée que j'ai c'est de supprimer tout caractère non disponible dans un clavier français avec un preg_replace (exemple : "/[^a-z0-9_ \t\r\n\v\f!@€éèçàù]/i"), mais au préalable de changer un grand bon nombre de caractère accentuer non disponible dans la langue de molière en caractère sans accents. De supprimer tous les doubles espaces triples, quadruples... sauts de ligne.


Ça comprend également la ponctuation seulement celle francais. Qu'en dites-vous ? à vus d'oeil je dirais que ca gênerais 1% des utilisateurs légitime.

Bien sûr certains caractères comme ces « guillemets » seront acceptés.

Edit : Pourquoi cette question, car ça me semble long de faire une fonction propre de ce type ! Donc je voudrais savoir si le prix en vaut la chandelle.

[gene69]

filter_var() a des qualités, pour les caractères accentués je ne dit pas (perso en utf8+xhtml j'ai pas de probleme). Ton probleme c'est la neutralisation des balises et des & qui empeche la page d'être valide.
str_replace va bien, htmlspecialchar aussi.

[ABCIWEB]

La réponse est : pourquoi faire ?

Pour la sécurité il suffit d'afficher tes données avec htmlentities ou htmlspecialchars.


Pour le reste il n'est pas intéressant, sauf cas très particuliers que je ne connais pas, de vouloir limiter ou de remplacer des caractères utilisés pour un commentaire.
On fait souvent des remplacements de caractères lors d'upload de fichiers afin d'avoir un nom de fichier valide pour le serveur, mais pour un commentaire je ne vois aucun intérêt.

[gene69]

parfois il est utile d'interdire les \0 et quelques autres caractères qui peuvent etre interpreté de façon aléatoire/inattendue si ton système est relié d'une façon ou d'une autre à un automate tier qui ne nétoie pas ses propres entrées.

Il se peut aussi que certaine de tes fonctions ne soit pas compatibles avec des chaines binaires et qu'un utilisateur malveillant n'hésitera pas à mettre des caractère qui ne sont pas sur ton clavier mais en utilisera d'autre (volontairement ou non d'ailleurs).

par exemple si tu autorises un retours à la ligne au milieux d'un champs mail, au moment ou tu écris les entêtes, tu peux, selon le code, ajouter des entetes pirates.

de même, tu ne te protege pas assez ton commentaire tu risques une injection de code javascript (pense à twiter) ou une simple injection sql. Mais il est vrai que htmlentity (attention aux quotes suffit pour 99% de l'usage web.

[nasuu]

J'utilise déjà htmlentities($value, ENT_COMPAT, "ISO-8859-1"); avant chaque affichage. Pareil pour mysql mysql_real_escape_string (et j'échape les caractères de recherche quand j'en fais une).

Quand je parle de sécurité, c'est que je partais du principe que moins il y a de caractère autorisé (je parle des inutiles comme les caractères chinois, etc..) Moins il y aura de risque dans les futures failles. Comme le caractère asiatique qui permet de faire une injection SQL via mysql_escape_string ou addslashes.

Mais apparament personne ne s'embête à nettoyer complètement une chaine. Ça m'encourage à faire un peu plus le fainéant sur cette fonction .

[ABCIWEB]

N'utilises pas addslashes mais utilises systématiquement mysql_real_escape_string pour protéger tes variables dans les requêtes et pas seulement pour des recherches. Alternativement tu peux utiliser des requêtes préparées mais mysql_real_escape_string est déjà une protection correcte.


Quel caractère asiatique permet de faire une injection SQL via mysql_real_escape_string ?

Et je fais comment si j'ai envie de te dire qu'un mot ou une expression française se traduit par tel ou tel caractère chinois ?

Comme dit plus haut, on limite l'emploi de certains caractères dans des cas très particuliers, le nom d'un fichier pour le rendre compatible, une adresse email avant de s'en servir dans un formulaire d'envoi de mail...
mais pour un commentaire ce serait embêtant. D'ailleurs je peux bien écrire ce que je veux dans ce forum <?php echo toto ?>
... en chinois mon prénom s'écrit ainsi 阿兰

[nasuu]

N'utilises pas addslashes mais utilises systématiquement mysql_real_escape_string pour protéger tes variables dans les requêtes et pas seulement pour des recherches. Alternativement tu peux utiliser des requêtes préparées mais mysql_real_escape_string est déjà une protection correcte.

Je n'ai jamais dit que j'utiliser les addslashes.

Quel caractère asiatique permet de faire une injection SQL via mysql_real_escape_string ?

Le caractère asiatique dont je te parle permettre d'ajouter un slash la ou il n'en allait pas, ce qui créer un bug dans les magiques quotes et addslashes. Si je me rappelle bien c'est un vieux caractère chinois qui n'est presque pas utilisé. Je ne serais te dire ou je l'ai lu. Mais c'est le livre Sécurité PHP 5 et MySQL qui m'avait lancé dans cette recherche. Le problème était lié au jeu de caractères. Donc mysql_escape_string était aussi ateind (car il ne se base pas sur le charset de la bdd). Si je me trompe que l'on me le dise.
ps : je n'ai pas dit mysql_real_escape_string mais mysql_escape_string.

Comme dit plus haut, on limite l'emploi de certains caractères dans des cas très particuliers, le nom d'un fichier pour le rendre compatible, une adresse email avant de s'en servir dans un formulaire d'envoi de mail...
mais pour un commentaire ce serait embêtant. D'ailleurs je peux bien écrire ce que je veux dans ce forum <?php echo toto ?>
... en chinois mon prénom s'écrit ainsi 阿兰

C'est vrai que ça peut être très gênant de ne pas pouvoir exprimer un mot tel qu'il est ou même une lettre. Mais je ne sais pas si ça nuit au référencement d'afficher un caractère chinois, tout en étant en latin1 (qui ne le gère pas) ?

[ABCIWEB]

Bah le référencement est une chose, la liberté d'expression du visiteur en est une autre... Pour le caractère chinois, c'était un exemple.

Si ce n'est pas trop tard tu devrais plutôt coder ton site en utf-8. Pas obligatoire mais recommandé car en plus de la gestion multi langues certaines fonctions php comme json_encode nécessitent l'utf-8. L'utf-8 te permettrait une bien meilleure évolution de ton site en cas de besoin...