Bonjour,

Je souhaiterais savoir s'il était possible, par un utilisateur pas très gentil d'injecter des caractères de contrôle à une page à travers un formulaire (j'ai essayé avec IE et ALT + 030 par exemple ne fonctionne pas, mais si j'envoyais les bits directement avec une application que j'aurais créé par exemple). Comment Php interpréterait-il (ou Apache) ces caractères ? Quelles pourraient en être les conséquences ? Est-il d'habitude de filtrer ces caractères (à défaut de faire une liste de caractères autorisés, qui serait énorme pour UTF-8, ce serait d'en interdire) ?

Enfin voilà ... votre avis

Merci d'avance pour votre réponse (je ne trouve rien sur internet) et a+

Pour se protéger des entrées de formulaire cf. htmlspecialchars et htmlentities pour l'affichage de ces entrées, et pour les bdd mysql_real_escape_string pour les injections, ou utiliser pdo.
Sinon il y a entre autre http://www.phpsecure.info/v2/zone/pArticle qui traite des pb de sécurité.

J'ai un autre problème. Php tourne normalement avec ISO-8859-1, on est d'accord. Lorsque je mets un formulaire-test, un caractère chinois est modifié en code html 㽏 si je suis en ISO, et en caractère chinois normal si je suis en UTF-8. Là, rien de chocant, j'imagine que c'est plutot bien (cela permet de mettre des caractères absents en ISO). Mais avec chr() et ord() j'ai pu remarqué que php utilisait AINSI (alors que sur le serveur de test, php tourne sous Linux) et non Latin1. La preuve : le signe € est 128 avec php, qui n'existe pourtant pas en Latin1 ... le caractère '1/4' ne possède pas le même code ASCII étendu que dans le tableau ISO-8859-1. Encore une fois ... il faut le savoir.

Mais mon problème se situe ailleurs ... alors que je me mets en encodage ISO-8859-1, je mets un formulaire sur une page test, et je fais un echo ... je teste œ et € ... et surprise ! Ils apparaissent très bien ! Comment des caractères inexistants dans un encodage peuvent-ils apparaitre ? Si je demande à UTF-8 de me lire du Latin1, à moins que ce soit la base ASCII, cela va poser de gros problèmes. Quelqu'un sait-il pourquoi ? Ou ai-je manqué quelque chose ... ?

Merci.

Rien à voir avec htmlenties, je parle des caractères de contrôle ... et puis le site possède des articles datant de 2003 ... Merci quand même.

En parlant de caractères de contrôle, le € sur mon test (voir ma réponse précédente) utilise le code ASCII 128 ... qui correspond sur ISO-8859-1 à un caractère de controle PAD. Mais là c'est encore un autre problème, c'est à croire que le navigateur utilise AINSI pour déencodé de l'ISO !

T'es pas net de te poser ce genre de question à cette heure ..

C'est un coup à perdre ses cheveux en avance ça ... méfit toi .. ca se dégarni vite là haut

Plus sérieusement , comment procèdes tu pour tes tests ?

je fais un echo ... je teste œ et € ... et surprise ! Ils apparaissent très bien ! Comment des caractères inexistants dans un encodage peuvent-ils apparaitre ? Si je demande à UTF-8 de me lire du Latin1, à moins que ce soit la base ASCII, cela va poser de gros problèmes. Quelqu'un sait-il pourquoi ? Ou ai-je manqué quelque chose ... ?

Ch...

Il y a au moins une chose qui fonctionne ... sous Notepad++ je choisis l'encodage ISO-8859-1 et je mets un €, et ouf ! quand je l'ouvre, le € a été changé par un "?". LUI AU MOINS IL RESPECTE !!

Ce que je me demande, c'est si les navigateurs sous windows n'envoient pas les données en AINSi malgré que je précise ISO-8859-1.

Mon code :
Donc le résultat est indépendant du codage de ma page Php (je peux meme la coder en UTF-8 ça ne changera rien et c'est normal). un chr(ord()) redonne bien le même résultat. Ce qu'il faudrait voir, c'est ce qu'il se passe si je fais chr(128) sur un navigateur tournant sur Linux. Ca expliquerait bien des choses. Mais cela veut dire que de tous les sites internet que j'ai pu concevoir, tout est mémorisé en AINSI et non en ISO ... et que les utilisateurs de Linux seraient pénalisés ... Ca me semble un peu gros. Si c'est ça --> Passage à l'UTF-8

En attendant, j'en ai marre de l'encodage, c'est tellement prise de tête au même titre que l'interprétation CSS et Javascript Par IE et Firefox (j'en ai fais l'amère expérience).

Je vais regarder Batman Begin (ou qqchose comme ça).

Ah alors c'est un problème d'encodage qui te fait poser des questions sur la sécurité/portabilité des données... ?

Si besoin il y a un tuto sur l'encodage utf8 ici et des infos complémentaires sur la config mysql dans ce topic

Comme tu le disais tu ferais bien de te mettre à l'utf-8 pour tes prochains sites car si tout est cohérent (entêtes apache, html, requête de config mysql si non accès à la config, enregistrement des fichiers etc.) tu n'auras plus de problèmes d'affichage avec les caractères spéciaux et aussi quelques avantages comme pouvoir travailler avec des fonctions php qui requièrent l'utf-8 comme JSON par exemple (sans compter les sites multilingues évidemment). C'est un peu pénible au départ mais finalement une habitude de travail que l'on acquiert très vite, et puis ce sera bientôt la config par défaut d' apache/mysql/php

Excuses pour le lien qui date (j'avais pas fait attention), mais cela dit les pb de sécurité sont toujours sur le même principe.

Rien à voir avec htmlenties, je parle des caractères de contrôle ... et puis le site possède des articles datant de 2003 ... Merci quand même.

En parlant de caractères de contrôle, le € sur mon test (voir ma réponse précédente) utilise le code ASCII 128 ... qui correspond sur ISO-8859-1 à un caractère de controle PAD. Mais là c'est encore un autre problème, c'est à croire que le navigateur utilise AINSI pour déencodé de l'ISO !

Mauvais test, refaire test. il n'y a pas de glyphe euro en ISO-8859-1 (et encore moins en ASCII, qui est une norme anglophone datant de 1961... Faut être un peu logique et chercher un peu quand on critique des articles de 2003 hein ). Par contre on trouve le glyphe euro à la position 128 dans un encodage proche, windows-1252

Pour citer wikipédia :

La distinction entre ASCII, ISO 8859-1, ISO 8859-15, Windows-1252 et MacRoman est une source de confusion parmi les développeurs de programmes informatiques.

Bon courage pour la suite.

Oui Calimero, c'est exactement ce que je dis ... MERCI DE LIRE MES QUESTIONS avant de répondre. Si je voulais utiliser de l'UTF-8, je le ferai. Mais fuir devant une situation que l'on ne comprend pas n'est pas une solution. Ca c'est de 1. De 2, BIEN Sûr que € n'existe pas en ISO-8859-1, puisque ca a été la base de mon étonnement, et pourtant, il s'affiche bel et bien sur un navigateur configuré pour l'ISO. Tout simplement, lorsque je fais

<?php
for ($i=0;$i<256;$i++) {
echo "<span style=\"margin:5px;float:left;\">$i:" . chr($i) . "</span>";
}
echo "<br /><br />";
for ($i=0;$i<256;$i++) {
echo "<span style=\"margin:5px;float:left;\">$i:" . htmlentities(chr($i)) . "</span>";
}
?>

dans les deux cas, il m'affiche la table de caractère AINSI. Pour un php utilisant ISO, je trouve ça spécial ... donc dans ce script, aparait en position 128 (qui est un caractère de controle ISO), le €.

sous windows il te le transcrit en Windows-1252 c'est pour ca que tu le vois, essaye avec us-ascii, ascii, iso-8859-1 pour lui tout ca il te le met en Windows-1252, mais pas le iso-8859-15

Et pourquoi

for ($i=0;$i<256;$i++) {
echo "<span style=\"margin:5px;float:left;\">$i:" . htmlentities(chr($i)) . "</span>";
}

m'affiche tous les codes ANSI et non ISO ? Cela veut dire PhP même tourne en ANSI alors qu'il est sur une plateforme Linux ... C'est ça qui me perturbe vraiment. Au début, je me suis dit que c'était une adaptation par rapport au €, on peut admettre que Windows utilise la plage des caractères de contrôle de ISO, mais Php ... pourquoi le fait-il lui ??? Je vois partout dans la doc de Php qu'il fonctionne sous ISO, et là que vois-je !

j'ai eu un doute sur le navigateur, mais meme en CLI il l'affiche

EDIT : non il l'affiche pas en CLI, par contre si je copie le résultat CLI dans notepad++ par exemple la il me sort le €, je pense que ducoup ca vient de l'environnement de lecture

http://browsershots.org/screenshots/d8a ... 273add3e8/

Je viens d'essayer sous Linux et il s'affiche. QUand je cherche "ISO-8859-1" sur Google, il y a plein de site qui mette la plage de AINSI à la place. Sachant que ISO-8859-1 ne POSSEDE PAS DE SIGNE €, ni de signe pour mille, ni de caractère OE, et pourtant ils apparaissent. C'est à se demander si la norme n'a pas changée depuis. Je vois aussi des sites qui disent que &#128; (en gros : € ici), n'est pas un caractère HTML valide et qu'il s'affiche mal sous Linux, et pourtant la capture d'écran prouve le contraire. C'est à en s'arracher les cheveux. j'avais un problème : Linjection de caractères de controle et maintenant j'en ai deux : AINSI à la place de ISO. Cela dit si AINSI est utilisé partout, ça ne me dérange pas. Mais dans ce cas, qu'on ne me parle pas d'ISO ! Il faut savoir !!

Je commence à trouver la solution ... Ce ne serait pas Php le "fautif", mais les navigateurs qui affichent les caractères en AINSI et non en ISO-8859-1 pour des raisons de compatiblité.

le test :

echo "<br /><br />" . ord(html_entity_decode('&euro;')); ne m'affiche pas 128 mais 38 (ce qui correspond au caractère &). Ce que je vois donc à l'écran, même sous Linux, n'est pas l'interprétation de php mais l'interprétation des navigateurs (qui pour éviter les problèmes d'affichage, interprète en AINSI).

Pareil pour utf8_encode($_GET['gg']) avec $_GET['gg] == '€' (sous ISO) : aucun caractère ne s'affiche, ou plutot des espaces. Cela montre que Php traite bien en ISO-8859-1 MAIS cela montre (c'était mon test 1), que Php accepte les caractères de contrôle. La question première est : qu'en fait-il ? Si j'arrive à envoyer à php un caractère hexadécimal 00 qui est "NUL", je vais donc avoir un caractère en plus sans le voir.