danger des editeurs wysiwyg ?

pssinjaune · 17 Février 2010

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

Marie-Aude · 17 Février 2010

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

dmathieu · 17 Février 2010

Au lieu de mettre du wysiwyg tu peut également mettre tes tags formattés.
Du markdown par exemple. http://daringfireball.net/projects/markdown/

spout · 17 Février 2010

Et pour le Markdown (et HTML, Wiki, BBCode,...) : http://markitup.jaysalvat.com/home/

passion · 17 Février 2010

merci beaucoup, je ne connaissais pas

C'est très sympa et plus clair que TinyMCE !

blman · 17 Février 2010

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.

honolulu · 17 Février 2010

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 {}...

HawkEye · 17 Février 2010

Très sympa cette petite fonction, Bruno.
Merci!

+Reco

passion · 17 Février 2010

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?

HawkEye · 17 Février 2010

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.

reglisse · 17 Février 2010

moi j'ai commencé à coder avec notepad c'est trop puissant comme editeurs wysiwyg

blman · 17 Février 2010

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.

Rod la Kox · 17 Février 2010

... 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. :-(

UsagiYojimbo · 17 Février 2010

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.

skyll · 17 Février 2010

excellent blman,
merci

(reco)

dop20vt · 17 Février 2010

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().

pssinjaune · 17 Février 2010

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.

Cliquez pour agrandir...

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 !

blman · 17 Février 2010

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)

pssinjaune · 17 Février 2010

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

blman · 17 Février 2010

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>

UsagiYojimbo · 17 Février 2010

Bein, si tu n'autorise pas <script> dans strip_tags, ça saute aussi non (ou alors j'ai raté un truc) ?

blman · 17 Février 2010

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...

blman · 17 Février 2010

http://www.manuelphp.com/php/function.preg-replace.php

Code:

$search = array ('@<script[^>]*?>.*?</script>@si');
$replace = array ('');
$text = preg_replace($search, $replace, $document);

Pas testé, pas optimisé, mais ça devrait fonctionner.

spout · 17 Février 2010

http://htmlpurifier.org/
http://htmlpurifier.org/comparison

dop20vt · 17 Février 2010

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 !!

Tony Monast · 18 Février 2010

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.

blman · 18 Février 2010

Dans le style, une confirmation de validation par email avant de publier l'article est souvent un très bon filtre anti-spam.

dop20vt · 19 Février 2010

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 !!

Bacteries · 19 Février 2010

Bah si on pense à la personne qui veut simuler un post on peut se dire qu'un captcha ne l'arrêtera pas.
La preuve :
https://www.google.com/search?q=captcha+reader

spout · 19 Février 2010

Et des exemples de CAPTCHA "crackés": http://caca.zoy.org/wiki/PWNtcha
La classe HTMLPurifier citée avant sert justement à protéger les failles XSS et en plus vérifie que le code HTML est valide.

dop20vt · 19 Février 2010

Bon ok jm'incline

Ca reste quand même de la grosse artillerie !!

Tony Monast · 19 Février 2010

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).

Leonick · 20 Février 2010

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.

jeyce · 23 Février 2010

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

Rod la Kox · 28 Juillet 2010

Un petit déterrage...

Aloha Editor : http://aloha-editor.com/index.html
Ca semble très sympa, original pour du wzw...

Quelqu'un a essayé ?

Leonick · 28 Juillet 2010

Rod la Kox a dit:
Quelqu'un a essayé ?

ça a l'air pas mal, surtout que ça fonctionne aussi sur IE8.
Je crois que je vais tester ça sur un de mes sites

pssinjaune · 28 Juillet 2010

Pas mal en effet, mais ca me parait quand meme pas mal limiter aux niveaux des fonctionnalités non ?

spout · 28 Juillet 2010

Pas mal du tout mais fort limité, il manque la possibilité de mettre des images.
Et aussi pour vendre des sites avec, il faut payer une licence commerciale

http://aloha-editor.com/license.html

Leonick · 28 Juillet 2010

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