danger des editeurs wysiwyg ?

WRInaute discret
Bonjour a tous,

Je me pose actuellement une question car je suis sur le developpement d'un site,
Les utilisateurs peuvent ecrire des articles, pour celà j'utilise un editeur wysiwyg (TinyMCE),
je me posait quelques questions de securités a ce sujet.

Quand l'editeur est en place tout est ok, si j'entre du code html dans mon TEXTAREA, celui si ne sera pas interpreté et apparaitra comme du texte une fois publié sur le site.

Le souci, c'est que si l'utilisateur desactive la fonction javascript de son navigateur, l'editeur wysiwyg n'est plus actif et n'apparait plus.
Le code html qui sera saisi sera cette fois interpreté et integré une fois publié sur le site.

Je prend l'exemple d'un IFRAME,
Avec l'editeur wysi actif, sur le site il apparaitra le code html, mais en aucun cas on ne pourra y voir l'iframe
Sans l'editeur wuysi, l'iframe sera interpreté comme un element html faisant parti du site.

La solution serait la fonction PHP htmlspecialchars("Mon Article"), qui permet d'indiquer qu'il s'agit de texte et qu'aucun element ne doit etre interpreté, mais du coup, l'editeur wysiwyg ne sert plus a rien puisqu'il servait a la mise en forme .

Y a t'il une solution securisante qui me permettrait de faire fonctionner l'editeur correctement et d'eviter qu'un petit malin integre du code HTML malicieu en desactivant la fonction JS de son navigateur ?

Merci d'avance pour vos reponses
 
WRInaute accro
Tout dépend du cms que tu utilises.
Tu peux aussi définir des filtres qui n'acceptent pour un type de contribution que certaines balises html
 
WRInaute accro
J'utilise aussi TinyMCE comme éditeur wysiwyg. Il est intégré dans le backoffice d'un site e-commerce et vu que mes rédacteurs font beaucoup de copier/coller depuis d'autres sites (ceux des fournisseurs), ça faisait souvent "sauter" ma mise en page à cause de code pas très propre qui était intégré lors du copier/coller.

J'ai donc configurer TinyMCE en mode simple pour qu'ils n'aient accès qu'aux fonctions simples de mise en page (gras, souligné, ...).
Et j'ai rajouté une fonction qui me nettoie l'HTML retourné :

Code:
function nettoieHTMLcode($code){

	//On nettoie le HTML
	$code=strip_tags($code, '<p><ul><li><strong><b><em><u><ol><lh><strike><i><dl><dt><dd><br><br/>');

	//On nettoie les classes, id et autres attributs
	$suppr=array('/[\s]{1}class=[\"\'].*?[\"\']/', '/[\s]{1}id=[\"\'].*?[\"\']/', '/[\s]{1}color=[\"\'].*?[\"\']/', '/[\s]{1}face=[\"\'].*?[\"\']/', '/[\s]{1}size=[\"\'].*?[\"\']/', '/[\s]{1}align=[\"\'].*?[\"\']/');
	$code=preg_replace($suppr, '', $code);
		
	return $code;
}

$articleDescriptif=nettoieHTMLcode($articleDescriptif);

striptags élimine toutes les balises HTML (sauf celles spécifiées en paramètre) ( http://php.net/manual/fr/function.strip-tags.php )
Et l'expression régulière enlève les attributs, classes et id qui pourraient être génant.
 
WRInaute impliqué
Le souci, c'est que si l'utilisateur desactive la fonction javascript de son navigateur, l'editeur wysiwyg n'est plus actif et n'apparait plus.

une idée serait alors de faire dépendre la soumission du formulaire de l'activation du javascript :wink:
si le js est activé, le submit est possible sinon {}...
 
WRInaute accro
J'ai aussi un prob avec tiny, c'est lorsque l'on fait sa page sur Words, le copier-coller sur Tiny rajoute une suite de code propre à Words !
As-tu testé aussi ta fonction avec Words?
 
WRInaute accro
Il y a de fortes chances que cette suite de code saute avec le strip_tags() ;)
Dans la fonction de Bruno, tout saute sauf les balises de mise en forme.
 
WRInaute accro
passion a dit:
J'ai aussi un prob avec tiny, c'est lorsque l'on fait sa page sur Words, le copier-coller sur Tiny rajoute une suite de code propre à Words !
As-tu testé aussi ta fonction avec Words?

Lorsque tu fais du copier/coller depuis word, ma fonction doit aussi supprimer ces tags spécifiques (Hawk a bien compris le principe ;) ). Sinon, il y a toujours moyen de l'améliorer cette fonction, elle n'est quand même pas très compliquée.

Sinon, TinyMCE a un bouton dans toutes les configuration : "cleanup messy code" (icone, petit pinceau ou mini balais, je sais pas trop). Ce bouton a la particularité de nettoyer le code des balises non html, il me semble.
 
WRInaute accro
... et fckeditor, vous avez un avis ?

Parce que c'est tout de même bien pratique ces petits modules. J'ai pas envi de me créer mon bbcode. :-(
 
WRInaute accro
Sur Fckeditor, il y a plusieurs variables dans le fckconfig.js pour nettoyer le code lors d'un copier-coller :

Code:
FCKConfig.ForcePasteAsPlainText	= true ;
FCKConfig.AutoDetectPasteFromWord = true ;	// IE only.

Par contre, fck est obsolète maintenant, c'est ckeditor.
 
WRInaute occasionnel
Pour le problème initial, moi je rajouterais un <input type="hidden" name="is_js" value="js_on" /> via javascript au chargement de la page.

Si $_POST['is_js'] == "js_on" alors le javascript est activé sinon pas de js et tu fais un strip_tags().
 
WRInaute discret
honolulu a dit:
Le souci, c'est que si l'utilisateur desactive la fonction javascript de son navigateur, l'editeur wysiwyg n'est plus actif et n'apparait plus.

une idée serait alors de faire dépendre la soumission du formulaire de l'activation du javascript :wink:
si le js est activé, le submit est possible sinon {}...

dop20vt a dit:
Pour le problème initial, moi je rajouterais un <input type="hidden" name="is_js" value="js_on" /> via javascript au chargement de la page.

Si $_POST['is_js'] == "js_on" alors le javascript est activé sinon pas de js et tu fais un strip_tags().

Malheureusement, cela n'est pas une solution.
Si la personne est malveillante au point de desactiver le JS pour inclure un code malicieu, il sera facile pour lui de se passer de la page de saisie du formulaire (exit donc le submit desactiver si JS desactiver), il lui suffira alors d'envoyer les bons parametres a la pages qui traite les donnees du formulaire et donc il mettra une variable $_POST['is_js'] = "js_on".

Je pense que je vais regarder du coté de la fction strip_tags() comme l'a sugeré balman, l'objectif etant biensur de ne pas enlever TinyMCE mais d'eviter que des petits malins essaye de contourner les limitations ;)

Merci en tous cas pour vos nombreuses réponses !
 
WRInaute accro
Alors, en plus de strip_tags, pense à rajouter un code qui enlève le javascript que cet utilisateur malicieux pourrait rajouter (genre une redirection vers son site)
 
WRInaute discret
merci blman pour ta nouvelle participation a ce topic,
Concernant un code js de redirection, aurait tu un exemple concret a me donner pour que j'effectue des tests sur mon site ?

merci a toi
 
WRInaute accro
Bein genre, le mec désactive javascript et entre dans le champ texte :

Code:
<script>
document.location.href="https://www.webrankinfo.com";
</script>

ou

Code:
<script language="javascript">
function tresChiant(){
 alert("Bip !");
 tresChiant();
}
tresChiant();
</script>

ou

Code:
<script type="text/javascript">
window.location.reload();
</script>
 
WRInaute accro
UsagiYojimbo a dit:
Bein, si tu n'autorise pas <script> dans strip_tags, ça saute aussi non (ou alors j'ai raté un truc) ?

oui effectivement. On aura juste du code javascript pas interprété mais visible dans la page...

Il suffirait de rajouter à ma fonction une instruction avant le strip_tags qui dirait un truc du genre :
tout ce qui est du genre <script *>*</script> (avec * = n'importe quelle chaine de caractère), alors on vire ce bout de code.
J'ai la flemme de faire l'expression régulière ce soir, c'est toujours prise de tête à faire. Si j'ai le courage, peut-être demain. Ou si quelqu'un se sent motivé, alors, c'est parti...
 
WRInaute occasionnel
pssinjaune a dit:
Malheureusement, cela n'est pas une solution.
Si la personne est malveillante au point de desactiver le JS pour inclure un code malicieu, il sera facile pour lui de se passer de la page de saisie du formulaire (exit donc le submit desactiver si JS desactiver), il lui suffira alors d'envoyer les bons parametres a la pages qui traite les donnees du formulaire et donc il mettra une variable $_POST['is_js'] = "js_on".

Je pense que je vais regarder du coté de la fction strip_tags() comme l'a sugeré balman, l'objectif etant biensur de ne pas enlever TinyMCE mais d'eviter que des petits malins essaye de contourner les limitations ;)

Merci en tous cas pour vos nombreuses réponses !

Enfin la ce n'est plus du tout un soucis lié à TinyMCE / javascript activé ou pas. C'est un problème de sécurité classique de formulaire.

Si tu veux éviter un POST en direct mets un captcha !!
 
Nouveau WRInaute
Bonjour,

dop20vt a dit:
Si tu veux éviter un POST en direct mets un captcha !!

Le captcha en lui-même est insuffisant pour empêcher un POST en direct et/ou pour empêcher l'injection malveillant de HTML/CSS/JS.

Pour une sécurité digne de ce nom, il vaut mieux purifier ce qui est envoyé et affiché. Une fois que c'est en place, là on peut ajouter quelques features pour empêcher les tentatives qui seront de toutes façons vouées à l'échec.
 
WRInaute accro
Dans le style, une confirmation de validation par email avant de publier l'article est souvent un très bon filtre anti-spam.
 
WRInaute occasionnel
Tony Monast a dit:
Le captcha en lui-même est insuffisant pour empêcher un POST en direct et/ou pour empêcher l'injection malveillant de HTML/CSS/JS.

J'aimerais bien savoir comment tu te débarrasses du captcha :?: A moins d'avoir un script d'analyse d'image pour retrouver le code mais la ca n'est pas à la portée du 1er venu !!
 
Nouveau WRInaute
dop20vt a dit:
J'aimerais bien savoir comment tu te débarrasses du captcha :?: A moins d'avoir un script d'analyse d'image pour retrouver le code mais la ca n'est pas à la portée du 1er venu !!

Que le captcha soit présent ou non, que le Javascript soit actif ou non, il est très facile de soumettre tout ce qu'on veut à un formulaire. Il existe des extensions et/ou des programmes qui :
  • Permettent de modifier le type des champs d'un formulaire, de changer leur longueur maximum, de transformer des menus déroulants en champs libres, de modifier la valeur des champs hidden, etc...
  • Permettent de modifier le comportement d'une fonction Javascript pas-à-pas, en changeant les variables à la volée, ce qui signifie qu'il serait tout à fait possible de bloquer l'auto-nettoyeur de TinyMCE directement dans la page en cours.
  • Permettent de modifier ce qui est envoyé en POST. On remplit le formulaire normalement, on écrit le CAPTCHA, on soumet le formulaire, mais juste après, on peut changer les valeurs envoyées avant que les données soient transmises au site.

Bref, la morale dans tout ça est que peu importe les moyens mis en places pour se protéger (captcha, javascript obligatoire ou rituel Voodoo), il ne faut jamais faire confiance aux données qu'on reçoit de l'utilisateur (cookies, GET, POST, CGI).
 
WRInaute accro
blman a dit:
Sinon, TinyMCE a un bouton dans toutes les configuration : "cleanup messy code" (icone, petit pinceau ou mini balais, je sais pas trop). Ce bouton a la particularité de nettoyer le code des balises non html, il me semble.
avec word, ça ne marche pas trop top : on est quand même obligé de passer faire le ménage dans le code brut
dop20vt a dit:
J'aimerais bien savoir comment tu te débarrasses du captcha :?: A moins d'avoir un script d'analyse d'image pour retrouver le code mais la ca n'est pas à la portée du 1er venu !!
le captcha c'est juste pour vérifier qu'on a bien un humain en face, pas que cet humain ne va pas essayer d'envoyer des données pour hacker. Une extension FF Tamper data permet ainsi de modifier toutes les données envoyées lors d'une requête.
 
Nouveau WRInaute
Il y a un plugin pour nettoyer les copier/coller, il faut ajouter:

plugins : "paste",
paste_auto_cleanup_on_paste : true,

dans l'init de tinyMCE
 
WRInaute accro
spout a dit:
Et aussi pour vendre des sites avec, il faut payer une licence commerciale :(
non, visiblement c'est uniquement si tu ne souhaites pas utiliser la licence AGPL3 qu'il faut que tu paies pour la licence commerciale
 
Discussions similaires
Haut