Controle des donnees entrees

[Pascale]

Bon, j'essaye une autre question...

Je travaille sur un site où des utilisateurs peuvent entrer des textes via
des formulaires.
Toutes les pages sont en iso-8859-15. Une fois contrôlées et validées, ces
données sont entrées dans diverses tables MySQL en UTF-8 Unicode.
Évidemment, faudrait pas qu'un utilisateur, par volonté de nuire ou par
ignorance, puisse entrer des données dangereuses...
Je suis allée voir la FAQ et j'ai recherché dans les archives, ce qui m'a
amenée à cette discussion : http://tinyurl.com/y4qycc et à la page
http://www.miakinen.net/vrac/charsets/

J'ai donc essayé d'appliquer les conseils donnés :
$ok = preg_match("|^([- @!%&()/*+?;:.0-9A-Za-z]|\xE2\x82\xAC|\xC2[\xA0-
\xBF]|\xC3[\x80-\xBF])*$|",$string);

Mais je me fais jeter à partir de xE2 :

Warning: preg_match(): Unknown modifier 'â'

En fait, tous les caractères codés en hexa sont rejetés.
Est-ce normal ?

Comment faut-il faire le test pour autoriser presque tout (sauf ce qui
pourrait être dangereux) :
- les caractères alphanumériques, y compris accentués, minuscules et
majuscules, cédilles en minuscule et majuscule
- les signes de ponctuation, apostrophes comprises, et si possible les
guillemets doubles
- quelques caractères spéciaux : &,@,/, symboles monétaires, parenthèses,
crochets, vrais guillements «», espaces insécables, si possible les œ, æ...

Bref, faut-il/peut-on les lister directement les caractères et écrire par
exemple (j'abrège) :

$masque="^([- @!%&()/*+?;:._&'"0-9A-Za-zéèêëçÇàâäùÉÈÊË])*$";

Ou y a-t-il un moyen plus adapté, plus pratique ?

[Olivier Miakinen]

Post by Pascale
[...]
Toutes les pages sont en iso-8859-15. Une fois contrôlées et validées, ces
données sont entrées dans diverses tables MySQL en UTF-8 Unicode.
Évidemment, faudrait pas qu'un utilisateur, par volonté de nuire ou par
ignorance, puisse entrer des données dangereuses...
Je suis allée voir la FAQ et j'ai recherché dans les archives, ce qui m'a
amenée à cette discussion : http://tinyurl.com/y4qycc

Tiens, c'est un de mes articles, ça.

Post by Pascale
et à la page http://www.miakinen.net/vrac/charsets/

Pas de doute, c'est à moi aussi. ;-)

Post by Pascale
\xBF]|\xC3[\x80-\xBF])*$|",$string);

Tiens, ça m'apprendra à tester mes bouts de code avant de les jeter en
pâture aux lecteurs et lectrices de fclp !

Post by Pascale
Warning: preg_match(): Unknown modifier 'â'

Et c'est là qu'il est parfois utile de lire le manuel en anglais plutôt
qu'en français, pour voir que ce qui s'appelle « option » en français
est nommé « modifier » en anglais :
http://fr2.php.net/manual/fr/reference.pcre.pattern.modifiers.php
http://fr2.php.net/manual/en/reference.pcre.pattern.modifiers.php

Le problème, c'est que j'avais choisi le « | » comme délimiteur plutôt
que le « / », ce qui marchait bien pour [- @!%&()/*+?;:.0-9A-Za-z] mais
qui coince dès le « | » d'alternative qui suit. Du coup, le caractère
suivant est considéré comme une option ([en] modifier) et ça foire.

Note que le caractère suivant n'est pas \xE2\x82\xAC (€ en UTF-8) mais
\xE2 (â en iso-8859-15) puisque tu dis toi-même que tes pages sont en
iso-8859-15. Ce n'était pas le cas de ma réponse à Phil P. en avril 2006
puisque je supposais UTF-8.

Post by Pascale
En fait, tous les caractères codés en hexa sont rejetés.
Est-ce normal ?

Ça l'est doublement, à cause de mon erreur et du fait que ma réponse
n'était pas adaptée à ton charset.

Post by Pascale
Comment faut-il faire le test pour autoriser presque tout (sauf ce qui
- les caractères alphanumériques, y compris accentués, minuscules et
majuscules, cédilles en minuscule et majuscule
- les signes de ponctuation, apostrophes comprises, et si possible les
guillemets doubles

Pour accepter à la fois les pattes de mouches simples et doubles
(« ' » et « " ») il doit falloir faire un traitement particulier
avant insertions dans la base, traitement dont je préfère ne rien
dire car c'est en dehors de mes compétences. Je laisse d'autres te
répondre.

Post by Pascale
crochets, vrais guillements «», espaces insécables, si possible les œ, æ...

Tu es en iso-8859-15, donc les seuls caractères que tu pourras recevoir
sont ceux de le table correspondante. Tu auras donc les « $ », « ¢ »,
« £ », « € », « ¥ », « œ » et « æ » sans aucun problème, ainsi que les
guillemets. En ce qui concerne l'espace insécable, tu peux l'accepter
mais il n'est pas dit que le visiteur saura la générer : certains
navigateurs la remplacent par une espace simple.

Post by Pascale
Bref, faut-il/peut-on les lister directement les caractères et écrire par
Ou y a-t-il un moyen plus adapté, plus pratique ?

Si tu veux accepter toute la partie haute d'iso-8859-15, tu peux même
utiliser des plages de caractères, par exemple À-ÿ pour toutes les
lettres accentuées majuscules et minuscules plus × et ÷, ou \xA0-ÿ
pour la totalité de la partie haute de la table. Note que, si tu as un
éditeur de texte qui ne te remplace pas l'espace insécable par une
espace simple, tu peux directement saisir cette espace insécable plutôt
que \xA0. Inversement tu peux préférer \xFF à ÿ si ça te semble plus
lisible.

Par ailleurs, puisque il n'y a plus de « | » intempestif, ceci devrait
marcher :
$ok = preg_match("|^[- @!%&()/*+?;:.0-9A-Za-z\xA0-\xFF]*$|",
$string);

Il y manque quelques uns des caractères que tu souhaitais. Je vais faire
une deuxième réponse séparée pour ça.

[Olivier Miakinen]

Voici donc ma deuxième réponse.

Post by Pascale
Comment faut-il faire le test pour autoriser presque tout (sauf ce qui
- les caractères alphanumériques, y compris accentués, minuscules et
majuscules, cédilles en minuscule et majuscule

numériques : 0-9
majuscules non accentuées : A-Z
minuscules non accentuées : a-z
majuscules accentuées plus Æ Ç × ß mais sans Š Ž Œ Ÿ : \xC0-\xDF
minuscules accentuées plus æ ç ÷ mais sans š ž œ : \xE0-\xFF
tous caractères accentués et d'autres trucs sans danger : \xA0-\xFF

Post by Pascale
- les signes de ponctuation, apostrophes comprises, et si possible les
guillemets doubles

signes de ponctuation : !,.:;?
éventuellement aussi : ()-/[]
apostrophes : '
guillemets doubles : " (c'est là je pense qu'est le plus gros problème)

Post by Pascale
crochets, vrais guillements «», espaces insécables, si possible les œ, æ...

symboles spéciaux : &@/
symboles monétaires : $ plus ceux qui sont déjà dans \xA0-\xFF
parenthèses, crochets : ()[]
vrais guillemets : sont déja dans \xA0-\xFF, de même que l'espace
insécable et les œ æ Œ Æ.
Il ne faut pas oublier non plus l'espace normale.

Post by Pascale
Bref, faut-il/peut-on les lister directement les caractères et écrire par
Ou y a-t-il un moyen plus adapté, plus pratique ?

Si tu n'avais pas besoin des ' et " j'aurais proposé :
"|^[] !$&(),./0-9:;?@A-Z[a-z\xA0-\xFF-]*$|"
Note à quel endroit j'ai mis le ] (au début pour qu'il ne ferme pas la
syntaxe [...]) et le - (à la fin pour que ce ne soit pas une série de
caractères consécutifs).

Mais puisque tu en as besoin, je dirais :
"/^[\x20-\x7E\xA0-\xFF]*$/"
... avec un traitement particulier pour les ' et ".

[Pascale]

Post by Olivier Miakinen
Note à quel endroit j'ai mis le ] (au début pour qu'il ne ferme pas la
syntaxe [...]) et le - (à la fin pour que ce ne soit pas une série de
caractères consécutifs).
"/^[\x20-\x7E\xA0-\xFF]*$/"
... avec un traitement particulier pour les ' et ".

Merci Olivier pour ces deux réponses très complètes que je m'en vas
éplucher (o;

Pour ce qui est des guillemets "", je peux difficilement les interdire dans
tous les champs (ou alors les transformer systématiquement en «» ?). Les
guillemets simples '' ne sont pas utiles dans le site en question et je
peux très bien interdire leur emploi (mais dans un autre site, sur lequel
je bosserai dans quelques temps, je pourrai à la rigueur interdire les
guillemets doubles mais pas les simples, car c'est un site botanique, et
ces guillemets simples servent à encadrer les noms de cultivars. Par par
exemple Cistus salviifolius 'Villeveyrac'). Sans compter que ce guillemet
simple (27 en hexa), c'est aussi l'apostrophe, donc je ne vois pas comment
l'interdire?

[Vincent Lascaux]

Post by Pascale
Évidemment, faudrait pas qu'un utilisateur, par volonté de nuire ou par
ignorance, puisse entrer des données dangereuses...

C'est pas ton boulot mais celui de mysql_real_escape_string de faire ca il
me semble (ou alors j'ai loupé la motivation)

[Pascale]

Post by Vincent Lascaux

Post by Pascale
Évidemment, faudrait pas qu'un utilisateur, par volonté de nuire ou
par ignorance, puisse entrer des données dangereuses...

C'est pas ton boulot mais celui de mysql_real_escape_string de faire
ca il me semble (ou alors j'ai loupé la motivation)

J'ignorais tout de cette fonction, merci Vincent : d'après l'aide PHP,
elle est indispensable ! Il suffirait donc d'utiliser cette fonction au
moment de l'insertion ou de la modification de données dans les tables SQL
pour se débarrasser des problèmes de ' et de " ?
J'ai jeté un coup d'œil à la configuration PHP chez notre hébergeur. Je
lis :

magic_quotes_gpc On On (local value et master value)
magic_quotes_runtime Off Off "
magic_quotes_sybase Off Off "

Faut-il changer quelque chose ou pas ?

Au juste, quels sont les caractères dangereux, ceux qu'ils faut interdire
dans un formulaire ? < et >, il me semble... et quoi d'autre ? Est-ce
vraiment une mauvaise idée d'interdire certains caractères plutôt que de
lister ceux qui sont autorisés dans le texte « tout venant » (sachant qu'il
existe déjà des contrôles spécifiques pour les adresses courriel, les mots
de passe, les URL) ?

[John GALLET]

Bonjour,

Post by Pascale
Il suffirait donc d'utiliser cette fonction au
moment de l'insertion ou de la modification de données dans les tables SQL
pour se débarrasser des problèmes de ' et de " ?

C'est exactement le type de fonctions qui souligne le genre de problèmes
qu'on a quand on gère des listes de choses interdites.

Post by Pascale
Au juste, quels sont les caractères dangereux, ceux qu'ils faut interdire
dans un formulaire ? < et >, il me semble... et quoi d'autre ?

Tout ce qui est dangereux... euh, oui mais comment on le trouve ? La liste
des choses autorisées parce que j'en ai besoin, ça je sais faire. La liste
de toutes les âneries possibles et (in)imaginables que l'on va balancer
dans la truffe de mes scripts, je n'en ai pas la moindre idée. Il y a des
gens très inventifs.

Post by Pascale
Est-ce vraiment une mauvaise idée d'interdire certains caractères plutôt que de
lister ceux qui sont autorisés

Oui, toujours une mauvaise idée. Même si parfois on s'en contente très
bien si on est conscient de ce qu'on fait.

Reprenons deux cas donc, < et > d'un côté, " et ' de l'autre.

La raison pour laquelle on interdit les deux premiers < et > c'est pour
désamorcer les XSS. Pour le moment, aucun navigateur n'est capable de
transformer &ltBODY ONLOAD=hackme_javascript()&gt; en un équivalent
exécutable et donc transformer < et > en leurs entités html suffit. Pour
le moment. Mais on peut avoir le même genre de gags que ce dessous en
attente.

La raison pour laquelle on échappe " et/ou ' (ça dépend de comment on
écrit son SQL) est double. Déjà pour que ça marche: quand je veux insérer
comme $nom="d'Artagnan"; il faut bien que INSERT...('$nom') ne devienne
pas ...('d'Artagan') // SQL ERROR mais bien ...('d'\'Artagan') ou
...('d''Artagan') // DEUX ' sous sybase par exemple).

Ensuite parce que dansles attaques possibles, il y a les injections SQL
sur les strings, et que si on échappe pas correctement ces caractères on
va ouvrir une faille. Mais si on travaille dans un charset "normal" comme
latin-1, on en a RIEN A F... de mysql_real_escape_string, un simple
addslashes suffit (ce qui est justement fait par défaut avec
magic_quotes_gpc). En revanche, si le charset de la table sur laquelle on
travaille accepte de traduire le code ascii de ' en sa valeur, comme
addslashes ne verra rien mais que la base traduira, la faille est toujours
présente si se contente de addslashes, qui en fait ne fait qu'établir ne
liste de caractères interdits.

Moralité : bien se poser la question de l'intérêt réel de s'emmerder à
jouer avec utf-8 au lieu de rester en charset usuel. D'ailleurs, et-ce
même logique ? A quoi servent les entités html comme &eacute; ou &agrave;
? N'oublions pas que HTML fonctionne parfaitement ***en ASCII 7 BITS !***
C'est **FAIT POUR**.

a++;
JG

[Pascale]

Post by John GALLET
Moralité : bien se poser la question de l'intérêt réel de s'emmerder à
jouer avec utf-8 au lieu de rester en charset usuel. D'ailleurs, et-ce
même logique ? A quoi servent les entités html comme &eacute; ou &agrave;
? N'oublions pas que HTML fonctionne parfaitement ***en ASCII 7 BITS !***
C'est **FAIT POUR**.

Merci pour les explications très claires. Seul le dernier paragraphe est
moins clair pour moi...
Nos pages sont en ISO 8859-15 mais à ma connaissance, chez notre hébergeur,
les tables sont en UTF8... quoique, je lis : Interclassement :
latin1_swedish_ci (ce swedish nous a toujous paru bizarre, mais on a déjà
essayé de le changer et déclenché je ne sais plus quelle cata). Il n'est
pas exclu que je confonde tout et n'importe quoi, mais dans ces histoires
de charsets, une chatte n'y retrouverait pas ses petits.

[John GALLET]

Post by Pascale
Nos pages sont en ISO 8859-15

Alors arrêtez de vous emmerder avec de l'utf-8.

Post by Pascale
mais à ma connaissance, chez notre hébergeur,
les tables sont en UTF8

Elles sont en ce que vous leurs dites d'être lors du create table (ou du
create database/création d'instance, selon le SGBDR).

Post by Pascale
... quoique, je lis : Interclassement : latin1_swedish_ci

Alors ça c'est encore un autre problème et une autre connerie "made in
mysql" (ou "comment emmerder la terre entière par défaut").

Post by Pascale
essayé de le changer et déclenché je ne sais plus quelle cata). Il n'est
pas exclu que je confonde tout et n'importe quoi,

Il y a trois acteurs, et donc autant de charsets acceptés possibles : le
navigateur, le middle-tiers (php) et le sgbdr (mysql). Si le middle-tiers
(php) n'assure pas la cohérence entre les trois, c'est la foire du
Trône avec Barbes à Papa (ou du ronron-croquette si on préfère). Le seul
problème si on colle tout le monde en entités html asci 7 bits et qu'on
arrête de s'emmerder c'est que l'ordre des résultats est faussé et que les
zones de stockage doivent être prévues beaucoup plus grandes. Donc de
manière générale, on préfère stocker "é" quand on le reçoit plutôt que
&eacute;.

Post by Pascale
mais dans ces histoires de charsets, une chatte n'y retrouverait pas ses
petits.

Meow.
Vu le bazar que ça met, j'irai même jusqu'à dire qu'une mère truie n'y
retrouverait pas ses petits gorets non plus.

a++;
JG

[Pascale]

Post by John GALLET
Meow.
Vu le bazar que ça met, j'irai même jusqu'à dire qu'une mère truie n'y
retrouverait pas ses petits gorets non plus.

Même conclusion...

Tiens, encore un truc que je ne m'explique pas, mais là, peut-être que la
solution est plus simple :
J'ai un beau formulaire à moi, avec de beaux champs en input type="text"
name="nom" etc.
Je rentre dans de ces très beaux champs du formulaire :

C'est mon "gros" chien Rocky

Je visualise dans un beau tableau le contenu de mon formulaire, je lis
bien : C'est mon "gros" chien Rocky. Avant d'afficher le contenu des
données entrées dans le formulaire, j'ai écrit
$_SESSION['nom']=$_POST['nom']. Je clique donc sur mon beau bouton
Corriger, qui me ramène au formulaire précédent en affichant dans le champ
texte le contenu de ma valeur de session.
Et là, horreur et malédiction, je lis : C'est mon . Tout ce qui est à
partir du " a disparu corps et bien.

Par contre, si je remplace dans le formulaire mon input type="text" par un
textarea name="nom", je peux mettre tous les guillemets que je veux, je
n'ai plus de problème d'affichage (et l'insertion des données dans la base
SQL est sans problème elle aussi).
D'une part, ça m'embête un peu de remplacer mes input type="text" par des
textarea (je trouve ça assez moche, même en ne mettant qu'une ligne), mais
en plus, j'aimerais comprendre pourquoi le fait de changer le type
d'élément de formulaire change quelque chose à la prise en charge des
guillemets.

[John GALLET]

Post by Pascale
J'ai un beau formulaire à moi, avec de beaux champs en input type="text"
name="nom" etc.

Oui mais la cause est dans le etc. Il y a aussi VALUE=

Post by Pascale
C'est mon "gros" chien Rocky
Et là, horreur et malédiction, je lis : C'est mon . Tout ce qui est à
partir du " a disparu corps et bien.

Ca dépend de ce qu'on regarde. Dans le navigateur, au mieux il y a ce
début de texte, sans erreurs par la suite, au pire il y a des décalages
incompréhensibles partour après. Il y a fort à parier que si on regarde
le HTML on verra :

<INPUT TYPE="text" NAME="nom" VALUE="C'est mon "gros" chien Rocky">

...et plouf les ". Si tu mets tes attributs entre ", il faut échapper les
" en les renvoyant, idem pour des attributs entre ' (les deux sont
autorisés si ma mémoire défaillante et la lecture des RFCs ad hoc par mon
collègue et ami le Dr Watson.. euh non flûte, Olivier M., sont correctes).

Post by Pascale
Par contre, si je remplace dans le formulaire mon input type="text" par un
textarea name="nom", je peux mettre tous les guillemets que je veux, je
n'ai plus de problème d'affichage

Logique, car alors le nom n'est plus dans un attribut entouré de ".

Post by Pascale
en plus, j'aimerais comprendre pourquoi le fait de changer le type
d'élément de formulaire change quelque chose à la prise en charge des
guillemets.

Il suffit de regarder le code HTML résultant.

a++
JG

[Pascale]

Post by John GALLET

Post by Pascale
J'ai un beau formulaire à moi, avec de beaux champs en input
type="text" name="nom" etc.

Oui mais la cause est dans le etc. Il y a aussi VALUE=

Value="$monbeautexte" exact ! J'aurais dû y penser...

Post by John GALLET
Ca dépend de ce qu'on regarde. Dans le navigateur, au mieux il y a ce
début de texte, sans erreurs par la suite,

Oui.

Post by John GALLET
au pire il y a des
décalages incompréhensibles partour après. Il y a fort à parier que
<INPUT TYPE="text" NAME="nom" VALUE="C'est mon "gros" chien Rocky">

Pile poil (c'est la cas de dire en parlant du chien...

Post by John GALLET
...et plouf les ". Si tu mets tes attributs entre ", il faut échapper
les " en les renvoyant, idem pour des attributs entre ' (les deux sont
autorisés si ma mémoire défaillante et la lecture des RFCs ad hoc par
mon collègue et ami le Dr Watson.. euh non flûte, Olivier M., sont
correctes).
Logique, car alors le nom n'est plus dans un attribut entouré de ".

Ben voilà, j'ai enfin pigé...

En fait, j'avais pas pensé jusque là à cette histoire de guillemets car
j'utilise en principe des « »... Il était temps que je revienne sur terre,
la plupart des gens utilisent des " ".

[Pascale]

Post by John GALLET
Si tu mets tes attributs entre ", il faut échapper les
" en les renvoyant, idem pour des attributs entre ' (les deux sont
autorisés si ma mémoire défaillante et la lecture des RFCs ad hoc par
mon collègue et ami le Dr Watson.. euh non flûte, Olivier M., sont
correctes).

Avant de tout passer en textarea j'ai essayé de faire ceci :

Formulaire (aucun changement) :

<input type="text" name="nomplante" size="50" maxlength="50" style="...;"
value="'.stripslashes($_SESSION['nomplante']).'">

Programme qui suit l'envoi du formulaire (test du contenu avec renvoi le
cas échéant au formulaire, affichage qui récapitule l'ensemble des données
entrées par l'utilisateur, possibilité de valider, de modifier,
d'abandonner). Je rajoute un addslashes qui n'y était pas :

$_SESSION['nomplante']=addslashes($_POST['nomplante']);

Si je saisis dans le formulaire :
C'est un très "gros" chien Rocky
puis si je clique sur Visualiser, et si je reviens sur le formulaire, je
lis :

C\'est un très \

(dans le code je lis : value="C\'est un très \"gros\" chien" )

Donc je crois que je ne vais pas me compliquer la vie, je vais passer mes
zones de saisie en textarea. L'inconvénient est que je ne peux pas limiter
le nombre de caractères saisis (je suis obligée de tronquer a posteriori),
sauf à utiliser un Javascript de décompte de caractères, ce qui ne
m'enthousiasme pas, trop compliqué à piger pour mon petit cerveau... et
j'aime bien comprendre ce que je fais (-:

[John GALLET]

Post by Pascale

Post by John GALLET
Si tu mets tes attributs entre ", il faut échapper les
" en les renvoyant,

Miardidiou, mauvais terme: pas échapper, traduire, transcoder.

Post by Pascale
(dans le code je lis : value="C\'est un très \"gros\" chien" )

Oui mais non, ce qu'il faut c'est transformer " en &quot; et pas en \" le
terme "échapper" que j'ai employé est impropre.

De manière générale, de toutes façons, on a intérêt à htmliser tout ce
qu'on renvoie au navigateur, tant pour raisons de compatibilité que
mesure anti-xss basique.

JG

[Pascale]

Post by John GALLET
Oui mais non, ce qu'il faut c'est transformer " en &quot; et pas en \"
le terme "échapper" que j'ai employé est impropre.

D'accord, je pige.

Post by John GALLET
De manière générale, de toutes façons, on a intérêt à htmliser tout ce
qu'on renvoie au navigateur, tant pour raisons de compatibilité que
mesure anti-xss basique.

Donc pas mal de caractères là encore : espaces insécables, caractères
accentués, ç et plein d'autres auxquels je ne pense pas forcément... Par
contre, je n'aimerais pas que les utilisateurs voient ces caractères à
l'écran lorsqu'ils reviennent sur leur formulaire (pour modifier) et je ne
voudrais pas que dans un champ où ils peuvent entrer, disons, 20
caractères, ils ne puissent en fait en entrer que 12 ou 15.
Plus j'apprends de choses, plus je vois l'étendue de ce qui me reste à
apprendre (:

[John GALLET]

Post by Pascale

Post by John GALLET
De manière générale, de toutes façons, on a intérêt à htmliser tout ce
qu'on renvoie au navigateur, tant pour raisons de compatibilité que
mesure anti-xss basique.

Donc pas mal de caractères là encore : espaces insécables, caractères
accentués, ç et plein d'autres auxquels je ne pense pas forcément...

Là peu importe, il y a des fonctions qui gèrent ça très bien.
Prends le temps de lire http://fr2.php.net/manual/en/ref.strings.php et en
particulier htmlentities() et htmlspecialchars().

Post by Pascale
contre, je n'aimerais pas que les utilisateurs voient ces caractères à
l'écran lorsqu'ils reviennent sur leur formulaire (pour modifier)

Le navigateur les interprètera : c'est son boulot. Quand tu lui envoies
&eacute; il affiche bien é.

Post by Pascale
voudrais pas que dans un champ où ils peuvent entrer, disons, 20
caractères, ils ne puissent en fait en entrer que 12 ou 15.

Toute vérification de la taille des champs côté client est vouée à 'échec
de toutes façons. Mettre un SIZE="10" détermine seulement la taille par
défaut du nombre de caractères affichés après interprétation. Ca n'empêche
pas l'utilisateur de saisir l'Encyclopédia Britannica s'il a du temps à
perdre. Enfin on va dire au moins le premier volume. Ou la lettre A du
Petit Larousse Illustré édition 1929 : les options ne manquent pas.

Post by Pascale
Plus j'apprends de choses, plus je vois l'étendue de ce qui me reste à

C'est une fois de plus de ma faute, j'aurais dû commencer par le bonjour
traditionnel sur ce forum et référencé dans la FAQ
(http://faqfclphp.free.fr/)

"Bienvenue chez les fous" :-) ((C)A.F. 1999)

a++
JG

[Olivier Miakinen]

Post by John GALLET

Donc pas mal de caractères là encore : espaces insécables, caractères
accentués, ç et plein d'autres auxquels je ne pense pas forcément...

Là peu importe, il y a des fonctions qui gèrent ça très bien.
Prends le temps de lire http://fr2.php.net/manual/en/ref.strings.php et en
particulier htmlentities() et htmlspecialchars().

Attention quand même aux surprises. Les fonctions htmlentities() et
htmlspecialchars() supposent par défaut que le jeu de caractères est
ISO-8859-1. Heureusement, depuis la version 4.1.0 il est possible de
préciser "ISO-8859-15" comme troisième paramètre.

Voir :
http://fr2.php.net/htmlentities
http://fr2.php.net/htmlspecialchars

[Pascale]

Post by John GALLET
Là peu importe, il y a des fonctions qui gèrent ça très bien.
Prends le temps de lire http://fr2.php.net/manual/en/ref.strings.php
et en particulier htmlentities() et htmlspecialchars().

J'ai essayé htmlspecialchars() (je n'ai pas forcément besoin de
htmlentities), et cela résout parfaitement mon problème ! Ce qui m'amène à
deux autres questions (1 de résolue, 2 qui se posent...) (-:

- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? Ou dois-je quand même contrôler les
caractères entrés comme me l'a expliqué Dr Watson dans un message
précédent ? (oui, je suis une feignasse, je l'admets...)

- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C&#039;est mon très &quot;gros&quot; chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non. Je peux « limiter les dégâts » en utilisant le
paramètre ENT_NOQUOTES au lieu de ENT_QUOTES puisque les ' ne sont pas un
problème, mais j'en connais qui risquent quand même de couiner parce que le
texte qu'ils ont saisi a été tronqué alors qu'ils avaient bien respecté le
nombre maxi de caractères...

Post by John GALLET
Toute vérification de la taille des champs côté client est vouée à
'échec de toutes façons. Mettre un SIZE="10" détermine seulement la
taille par défaut du nombre de caractères affichés après
interprétation. Ca n'empêche pas l'utilisateur de saisir
l'Encyclopédia Britannica s'il a du temps à perdre. Enfin on va dire
au moins le premier volume. Ou la lettre A du Petit Larousse Illustré
édition 1929 : les options ne manquent pas.

Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut normalement pas
saisir plus de 10 caractères. Si ?

Post by John GALLET
C'est une fois de plus de ma faute, j'aurais dû commencer par le
bonjour traditionnel sur ce forum et référencé dans la FAQ
(http://faqfclphp.free.fr/)

Mais non, c'est pas de ta faute, car l'adresse de la FAQ, je la connais,
elle est même dans mes favoris, mais j'oublie souvent de la consulter alors

Post by John GALLET
"Bienvenue chez les fous" :-) ((C)A.F. 1999)

Je m'disais aussi... (o;

[John GALLET]

Re,

Post by Pascale
J'ai essayé htmlspecialchars() (je n'ai pas forcément besoin de
htmlentities), et cela résout parfaitement mon problème ! Ce qui m'amène à
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés

Ca dépend où on l'appelle et ça dépend de quel type d'attaque. Petite
galerie des horreurs possibles et quelques remèdes sur
http://www.saphirtech.com/securite.html

Post by Pascale
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient

En effet, si on fait la modification avant le stockage, comme je
l'indiquais déjà dans ce thread, il faut prévoir des tailles supérieures.
Cela a aussi d'aures effets de bord, en particulier sur le ORDER BY.

Post by Pascale
problème, mais j'en connais qui risquent quand même de couiner parce que le

Rôôh, meuuuh non, les utilisateurs ? Couiner pour ça ? Pourquoi
*seulement* pour ça ?

Post by Pascale
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut normalement pas
saisir plus de 10 caractères. Si ?

Tout dépend de ce qu'il utilise comme clickodrome. Je t'assure que mon
lynx s'en foutra éperdument, et quand à wget ou curl, je te dis même pas.
Donc il faut voir à quoi/qui sert cette restriction si elle est faite côté
cient. Si c'est pour lui indiquer visuellement qu'au delà de telle taille
il risque de se faire zapper, c'est suffisant.

Bon, reprenons la logique et les contraintes.

On veut saisir un texte dans un clickodrome, le stocker en sgbdr, et le
restituer. Ca devrait pas être si difficile que ça sur le papier. En
pratique, pour pas se faire tarter au passage, c'est moins facile.

Concernant le filtrage des données en entrée, depuis des années, c'était
demerden zie sich elein. Depuis peu, l'extension filter est disponible :
http://fr2.php.net/manual/en/ref.filter.php

A éplucher pour voir si le comportement te convient.

Ensuite, faut-il désamorcer en entrée ou en sortie ? Perso je désamorce en
entrée, quitte à refaire l'opération inverse en sortie si finalement mon
canal n'est pas du html. D'aucuns font l'inverse.
Faut-il désamorcer les xss en convertissant les < et les > ou en utilisant
strip_tags ? Bonne question. La seconde bouffe tout ce qui se trouve entre
< et > sans autre forme de procès, même si ce n'est pas du html :
a<b et b>c => ac

Ca m'empêche pas de l'utiliser, tout dépend du besoin potentiel des
utilisateurs d'entrer ce genre de choses. Dans une application de commerce
électronique, le besoin est totalement nul, pas plus en frontal qu'en
backoffice.

Et enfin les problèmes d'affichage, comme les " perdues dans des
attributs. La seule solution est de les transformer au moment où on les
renvoie vers le navigateur, ou de les avoir transformées avant stockage
dans le sgbd.

a++; JG

[Pascale]

Post by John GALLET
Ca dépend où on l'appelle et ça dépend de quel type d'attaque. Petite
galerie des horreurs possibles et quelques remèdes sur
http://www.saphirtech.com/securite.html

Grmpf. Je suis sûre que c'est affreux, je m'absente jusqu'à mardi, je crois
que je vais garder ça pour mon retour.

Post by John GALLET
En effet, si on fait la modification avant le stockage, comme je
l'indiquais déjà dans ce thread, il faut prévoir des tailles
supérieures. Cela a aussi d'aures effets de bord, en particulier sur
le ORDER BY.

[OUI] et ça m'embête un peu.

Post by John GALLET

Post by Pascale
problème, mais j'en connais qui risquent quand même de couiner parce que le

Rôôh, meuuuh non, les utilisateurs ? Couiner pour ça ? Pourquoi
*seulement* pour ça ?

Ce serait étonnant en effet (o; Il y a forcément ceux qui vont trouver que
« c'était mieux avant », ceux qui vont trouver que c'est écrit trop petit,
trop gros, que les couleurs sont trop ternes, ou au contraire font mal aux
yeux, qu'il n'y a pas de CSS et que c'est une honte en 2007 (le site ne
sera pas en ligne avant), que l'aide n'est pas assez complète, ou au
contraire trop détaillée, etc.

Post by John GALLET

Post by Pascale
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut
normalement pas saisir plus de 10 caractères. Si ?

Tout dépend de ce qu'il utilise comme clickodrome. Je t'assure que mon
lynx s'en foutra éperdument, et quand à wget ou curl, je te dis même
pas. Donc il faut voir à quoi/qui sert cette restriction si elle est
faite côté cient. Si c'est pour lui indiquer visuellement qu'au delà
de telle taille il risque de se faire zapper, c'est suffisant.

Oui, c'est le but.
D'une manière générale, je me demande toujours ce que mon code va donner
chez l'utilisateur. Je teste sur Opera, Firefox, IE, je trouverai bien un
pote pour me dire ce qu'ne pense Safari, mais sorti de là...

Post by John GALLET
Bon, reprenons la logique et les contraintes.
On veut saisir un texte dans un clickodrome, le stocker en sgbdr, et
le restituer. Ca devrait pas être si difficile que ça sur le papier.
En pratique, pour pas se faire tarter au passage, c'est moins facile.

Voilà.

Post by John GALLET
Concernant le filtrage des données en entrée, depuis des années,
c'était demerden zie sich elein. Depuis peu, l'extension filter est
disponible : http://fr2.php.net/manual/en/ref.filter.php
A éplucher pour voir si le comportement te convient.

Gloups. Va falloir que je m'y penche sérieusement, ça n'a pas l'air
simple... Le manuel PHP renvoie vers une autre adresse qui a l'air
intéressante elle aussi : http://phpro.org/tutorials/Filtering-Data-with-
PHP.html

Post by John GALLET
Ensuite, faut-il désamorcer en entrée ou en sortie ? Perso je
désamorce en entrée, quitte à refaire l'opération inverse en sortie si
finalement mon canal n'est pas du html. D'aucuns font l'inverse.
Faut-il désamorcer les xss en convertissant les < et les > ou en
utilisant strip_tags ? Bonne question. La seconde bouffe tout ce qui
se trouve entre < et > sans autre forme de procès, même si ce n'est
pas du html : a<b et b>c => ac
Ca m'empêche pas de l'utiliser, tout dépend du besoin potentiel des
utilisateurs d'entrer ce genre de choses. Dans une application de
commerce électronique, le besoin est totalement nul, pas plus en
frontal qu'en backoffice.

Je sais que certains utilisateurs risquent par exemple de saisir dans leurs
commentaires des adresses de sites entre <> pour appuyer leurs propos, mais
dans les autres champs, je peux virer sans état d'âme ce qui se trouverait
entre <>. Je peux aussi préciser dans l'aide de ne pas utiliser de <>, que
tout ce qui sera entre sera ratatiné, mais bon, ça suppose que les
utilisateurs lisent l'aide.

Post by John GALLET
Et enfin les problèmes d'affichage, comme les " perdues dans des
attributs. La seule solution est de les transformer au moment où on
les renvoie vers le navigateur, ou de les avoir transformées avant
stockage dans le sgbd.

Et là, sauf si j'ai pas bien suivi, on retombe sur les problèmes de tri qui
peuvent être perturbés par les caractères spéciaux (reste à voir si ce
serait si catastrophique que ça...) et des champs à prévoir plus grands
dans les tables SQL. Mais, grosso modo, l'& étant peu employée, il n'y
aurait guère que les " " pour être « transformés » si j'utilise par
ailleurs strip-tags. C'est ça, j'ai pas trop dit de c...eries ?

[Olivier Miakinen]

Post by Pascale
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]

En fait, dans une valeur d'attribut, les balises HTML on s'en tape un
peu. Les caractères dangereux ne sont pas les mêmes à l'intérieur d'une
balise qu'à l'extérieur.

Post by Pascale
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C&#039;est mon très &quot;gros&quot; chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.

Tu vas t'en vouloir de ne pas y avoir pensé toi-même, j'en suis sûr :
contrôler la longueur *avant* de transformer les caractères en entités !

Post by Pascale

Post by John GALLET
Toute vérification de la taille des champs côté client est vouée à
'échec de toutes façons. Mettre un SIZE="10" détermine seulement la
taille par défaut du nombre de caractères affichés après
interprétation. Ca n'empêche pas l'utilisateur de saisir
l'Encyclopédia Britannica s'il a du temps à perdre. Enfin on va dire
au moins le premier volume. Ou la lettre A du Petit Larousse Illustré
édition 1929 : les options ne manquent pas.

Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut normalement pas
saisir plus de 10 caractères. Si ?

D'une part je suis pas sûr que ce soit vraiment interdit par le
navigateur, mais aussi et surtout un utilisateur malintentionné
peut parfaitement ignorer cette directive et envoyer n'importe
quelle requête.

[John GALLET]

Post by Olivier Miakinen

Post by Pascale
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]

En fait, dans une valeur d'attribut, les balises HTML on s'en tape un
peu. Les caractères dangereux ne sont pas les mêmes à l'intérieur d'une
balise qu'à l'extérieur.

Ne pas trop tirer de plans sur cette comète là, en termes de caractères
comme en termes de "cheval de troie" dans un attribut perdu. Il y a des
gens qui savent être super inventifs dans ce registre.

Un petit tour sur http://ha.ckers.org/xss.html permet de se faire des
frayeurs. Personnellement, j'adore ce genre là :

<IMG SRC='vbscript:msgbox("XSS")'>
ou
<IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))">

qui cassent totalement toute tentative de recherce de mot clef.

Post by Olivier Miakinen

Post by Pascale
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C&#039;est mon très &quot;gros&quot; chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.

contrôler la longueur *avant* de transformer les caractères en entités !

Le problème est surtout d'estimer à l'avance quelle taille on veut en
sgbd. Mettons qu'on estime que le luser ne rentrera pas plus de 50 chars.
Oui, mais 50 chars passés à htmlentities, ça fait combien ? 100 ? 200 ? On
se retrouve vite à mettre des BLOB à la place d'un char(20) :-)

JG

[Pascale]

Post by John GALLET
Le problème est surtout d'estimer à l'avance quelle taille on veut en
sgbd.

Oui, et comme tu le disais dans un autre message, il y a aussi un impact
sur les tri et les recherches. Je comptais mettre un moteur de recherche
sur les noms de plantes entrés dans la table, voire sur le descriptif
des plantes en question... Et je travaille aussi sur un autre site où les
tris alphabétiques (noms d'associations) sont beaucoup plus employés, et
les users encore plus... euh... inventifs.

Post by John GALLET
 Mettons qu'on estime que le luser ne rentrera pas plus de 50
chars. Oui, mais 50 chars passés à htmlentities, ça fait combien ? 100
? 200 ? On se retrouve vite à mettre des BLOB à la place d'un char(20)
:-)

Maishhheuuuuuu.... (o;

[Vincent Lascaux]

Post by Pascale
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien »
devient
« C&#039;est mon très &quot;gros&quot; chien »

La base de donnée devrait contenir l'information (C'est mon très "gros"
chien) plutot que sa représentation sous forme HTML. Ca évitera bien des
soucis quand on voudra utiliser l'information pour autre chose que du HTML
(et du même coup ca résoud tes autres problemes). Donc stoquer les données
telles quelles dans la base et utiliser htmlentities sur les données qu'on
affiche sur la page (qu'elles viennent de l'utilisateur ou pas).

[Pascale]

Post by Vincent Lascaux
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML. Ca évitera
bien des soucis quand on voudra utiliser l'information pour autre
chose que du HTML (et du même coup ca résoud tes autres problemes).

Oui !

Post by Vincent Lascaux
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).

J'avoue que je ne comprends pas trop : si je fais cela, est-ce que mes
données seront protégées contre l'injection de scripts malveillants et
autres méchancetés ?

[John GALLET]

Post by Pascale

Post by Vincent Lascaux
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML.

Vieux débat.

Post by Pascale

Post by Vincent Lascaux
Ca évitera bien des soucis

Ca évitera un appel de fonction qu'on ferait sinon systématiquement dans
le cas de l'output html...

Post by Pascale

Post by Vincent Lascaux
quand on voudra utiliser l'information pour
autre chose que du HTML

Encore faut(il en avoir le besoin.

Post by Pascale

Post by Vincent Lascaux
(et du même coup ca résoud tes autres problemes).

Non.

Post by Pascale

Post by Vincent Lascaux
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).

J'avoue que je ne comprends pas trop : si je fais cela, est-ce que mes
données seront protégées contre l'injection de scripts malveillants et
autres méchancetés ?

Ca dépend lesquelles et ça dépend des traitements.

Deux méthodes avec leurs caractéristiques.
Tronc commun aux deux méthodes, but éviter les injections SQL.

Les données brutes sont dans $_GET/POST/REQUEST. On échappe les ' (et "
selon la syntaxe SQL) et on vérifie que les entiers sont bien des entiers.
Ceci permet de faire sereinement des requêtes SQL, par exemple pour
stocker du texte qu'on renverra plus tard à un navigateur.

Maintenant le besoin est de protéger le navigateur en sortie contre les
XSS.

Méthode 1: on n'a pas envie d'oublier un htmlentities/sp dans un coin en
sortie. Donc on désamorce avant stockage au même endroit que ce qui fait
le traitement précédent. Ca a des effets de bord, comme les tailles, order
by etc. Si on veut un autre canal de sortie, ou on prend le méthode 2 ou
on fera l'opération inverse sur ce canal. Quand on fait un echo quel qu'il
soit, venant de la base ou d'une variable locale, c'est bien echo, on a
désamorcé avant. Moi je ne supporte pas l'idée de devoir faire attention à
chaque ligne de code parce que j'ai des variables piégées: un jour ou
l'autre, malgré toute l'attention que je porte à mon codage, j'en
oublierai une, c'est évident "by design".

Méthode 2: on se trimballe des variables piégées partout. Donc on les
stocke en base de données, ce qui ne créee pas d'effets de bord à ce
niveau là. Quand on veut les renvoyer au navigateur, on dératise. Dit
autrement, on doit bannir toute utilisation de echo/print/printf(%s) et
avoir une fontion/méthode qui démine systématiquement la sortie en
fonction du canal.

On ne peut pas bestialement travailler avec ob_start() et htmliser tout le
flux de retour car y compris le html serait rendu inopérant, ou alors il
faut jouer avec une callback et des marqueurs et du parsing. Si on
utilise un moteur de templates un peu intelligent, on doit pouvoir faire
avec, en ne s'emmêlant pas les crayons quand on génère dynamiquement un
lien a href par exemple.

Les deux méthodes ont leurs avantages/inconvénients. Je suis venu à la
première par factorisation du code et simplification. La seconde est plus
logique, plus "normale". Mais trop besogneuse à mon goût, si faille il y a
on ne la verra que quand il sera trop tard. L'essentiel est de faire un
choix conscient des forces et faiblesses de ses méthodes.

Attention à ce propos : dans les choses qu'on renvoie au navigateur, il y
a trois catégories.

- le texte pur. Là on interdit les < et > pour désamorcer, ça suffit.
- le texte acceptant le html. Là les ennuis sérieux commencent.
- les données binaires. N'oubliez pas que les images et les vidéos et
flash SONT DES VECTEURS DE XSS (et d'injections de code php) et doivent
être désamorcés COMME LES AUTRES. Et là je serai catégorique, on désamorce
AVANT stockage, *AUCUNE* raison n'existe de le faire à l'envoi.

a++
JG

[Pascale]

Post by John GALLET
Deux méthodes avec leurs caractéristiques.
Tronc commun aux deux méthodes, but éviter les injections SQL.
Les données brutes sont dans $_GET/POST/REQUEST. On échappe les ' (et
" selon la syntaxe SQL) et on vérifie que les entiers sont bien des
entiers. Ceci permet de faire sereinement des requêtes SQL, par
exemple pour stocker du texte qu'on renverra plus tard à un
navigateur.

D'acc.

Post by John GALLET
Maintenant le besoin est de protéger le navigateur en sortie contre
les XSS.
Méthode 1: on n'a pas envie d'oublier un htmlentities/sp dans un coin
en sortie. Donc on désamorce avant stockage au même endroit que ce qui
fait le traitement précédent. [couic]

À lire ça, je préfère la première méthode, sans hésitation.

Post by John GALLET
Les deux méthodes ont leurs avantages/inconvénients. Je suis venu à la
première par factorisation du code et simplification. La seconde est
plus logique, plus "normale". Mais trop besogneuse à mon goût, si
faille il y a on ne la verra que quand il sera trop tard. L'essentiel
est de faire un choix conscient des forces et faiblesses de ses
méthodes.

Je ne sais pas si mes raisons sont les bonnes, mais en effet, la première
méthode me semble plus sûre, plus logique.

Post by John GALLET
Attention à ce propos : dans les choses qu'on renvoie au navigateur,
il y a trois catégories.
- le texte pur. Là on interdit les < et > pour désamorcer, ça suffit.
- le texte acceptant le html. Là les ennuis sérieux commencent.
- les données binaires. N'oubliez pas que les images et les vidéos et
flash SONT DES VECTEURS DE XSS (et d'injections de code php) et
doivent être désamorcés COMME LES AUTRES. Et là je serai catégorique,
on désamorce AVANT stockage, *AUCUNE* raison n'existe de le faire à
l'envoi.

Dans le site sur lequel je travaille actuellement, les utilisateurs peuvent
passer du texte brut et des images.

Si je comprends bien, pour le texte brut, on peut à la rigueur se borner à
échapper ' et " et à interdire < et >. Est-ce que ça vaut le coup de faire
plus compliqué ?
Pour les images, je teste plusieurs choses : le poids avec
$_FILES['photo2']['size'] < 20 car j'ai vu que si la photo transmise est
d'une taille supérieure à celle qui est précisée dans MAX_FILE_SIZE, je
peux me retrouver avec un fichier fantôme de quelques octets. Bien sûr, je
teste aussi l'extension, en allant voir la chaîne de caractères qui est
derrière le . , afin de savoir si c'est un jpeg, jpg, JPG ou JPEG. Je
vérifie aussi que $_FILES['photo2']['tmp_name'] n'est pas vide et que
$_FILES['photo2']['error'] est bien égal à 0.
Pour l'instant j'en suis là, c'est-à-dire pas bien loin (: .

[Olivier Miakinen]

'<input type="text" value="'.stripslashes($value).'">'
[...]
(dans le code je lis : value="C\'est un très \"gros\" chien" )

peut-être :

'<input type="text" value="'.str_replace('"', '\\"', $value).'">'

ou :

"<input type='text' value='".str_replace("'", "\\'", $value)."'>"

voire :

$value = str_replace("'", "\\'", $value);
"<input type='text' value='$value'>"

[Pascale]

Post by Olivier Miakinen
'<input type="text" value="'.str_replace('"', '\\"', $value).'">'
"<input type='text' value='".str_replace("'", "\\'", $value)."'>"
$value = str_replace("'", "\\'", $value);
"<input type='text' value='$value'>"

Je vais essayer de tester ces différentes solutions, merci : j'ai
l'embarras du choix (: