Plantage écran scénario

[lpb85300]

Bonjour,

Cas de figure : un bloc Action, avec un bloc Si intégré. Lorsqu’on utilise la syntaxe pour assertion arrière - matches « /(?<!(chambre))/ » -, panique à bord. Ca enregistre, ça réactualise la page, les actions possibles sur le bloc Action disparaissent, et en cas de nouvelle sauvegarde dans la foulée, ça supprime complètement le bloc Si.

Plus simplement, dès que l’on saisit les caractères « <! » de suite dans un champ, ça plante le traitement, et ça efface une bonne partie du scénario.
Il doit y avoir un conflit dans la gestion de ce type de données (façon htmlentities) et le HTML généré doit ainsi le confondre avec l’ouverture d’une balise HTML de type <!–

[lpb85300]

Pour + de détails, le plantage se fait dans le fichier scenario.js lors de la création du bloc preview

<div class="blocPreview"><!--</div--></div>

[Loic]

Bonjour
Oui c’est connu malheureusement il est quasi impossible de corriger désolé

[lpb85300]

J’ai du mal à comprendre la réponse, surtout le « quasi impossible de corriger ».

On parle bien de cette ligne là ? =>

retour += '<div class="blocPreview">'+_subElement.expressions[0].expression.substring(0,200)+'</div>'

Si l’origine est bien là, un équivalent de htmlentities PHP en javascript sur le substring devrait faire l’affaire ?
Maintenant, comme je ne connais pas tous les tenants et aboutissants, pe que cette correction a d’autres effets de bord que je ne vois pas ?

[lpb85300]

Bon, perso je viens de taffer sur un simple script pour htmlentitiser (entités HTML de < > et &) et ça fonctionne parfaitement. À voir si quelqu’un a une objection, sinon je ferai un PR de la solution.

[Loic]

Là ça marche dans ton cas mais par expérience ça va sûrement casser d’autre truc…

[lpb85300]

Ca me parait quand même être très approximatif là.

Si je ne dis pas de bêtises, tu es dans la Team officielle de développement de Jeedom. Tu dois donc (ou quelqu’un près de toi) être au courant du dev’ du core et des fonctionnalités, et les maîtriser. Car même si ça manque en doc’ technique, on peut comprendre le rôle de cette fonction.

Suivant le clic de l’utilisateur sur l’oeil (afficher/masquer le bloc), on affiche ou non le bloc preview préalablement construit.

Ce bloc preview est construit depuis la première expression sous-jacente saisie par l’utilisateur, et seuls ses 200 premiers caractères sont affichés. Le but de ce bloc preview est uniquement de l’affichage dans une balise div grisée à l’utilisateur. Grosso modo, il s’agit ici d’une simple information, partielle qui plus est.

De fait, le contenu de bloc preview ne devrait jamais contenir de balise HTML pouvant être exécutée. C’est la base du développement, et un des principes de rédaction texte/markdown des forums : filtrer et interdire au maximum l’interprétation du HTML. Il s’agit d’une faille de sécurité XSS permettant d’injecter du code qui pourrait être exploité à des fins inappropriées. Ici, c’est une simple balise qui fait dérailler.

Imaginons que je veuille aller un peu plus loin, en ajoutant ceci comme expression
<img src="https://www.wallpapertip.com/wmimgs/26-263619_bubbles-on-pink-background-stock-photo-hd-public.jpg" />
Ca affichera tranquillement une image dans le bloc preview. La prochaine étape est d’intégrer un appel à un script javascript tiers dedans, et on peut facilement deviner les conséquences d’une telle saisie : installation malicieuse d’un plugin, achats sur le market, récupération d’informations de configuration…

Donc, in fine, cette fonction DOIT être bornée dans un objectif de sécurité, mais je n’ai pas encore relu tout le script (il y a pas mal de modifs à faire, le code n’est pas factorisé. Je vais modifier et faire une PR. Aux équipes et bêta-testeurs ensuite de valider ou invalider mon dev’ pour sécuriser tout ça, et améliorer le quotidien de tous

[Loic]

Oui oui je connais bien cette partie c’est moi qui l’ai écris. Je sais aussi par expérience que même un truc annondin comme ça peut avoir de lourde conséquence.

Pour la faille xss oui elle existe (et yen a bcp d’autres dans jeedom de ce genre) mais seul l’utilisateur peut écrire dedans donc l’utilisateur s’auto attaque c’est limité quand même.

Après pas de soucis pour le pr j’ai une nouvelle politique de les accepter vu qu’on me reproche d’être trop strict après par contre si ya un soucis sur un bout de code qui n’est pas de moi pas de support de ma part je n’ai pas la compétence.

[lpb85300]

Voilà, dev’ fait et testé

PR #1824 lancée.

[Loic]

Bonjour,
Merci c’est mergé