Bug #15431
fermé
Dans un contenu wysiwyg (webPage, contenu de dossier,etc..) impossible d'ajouter une iframe pointant vers un permalien d'un fichier Silverpeas
0%
Mis à jour par Miguel Moquillon il y a environ un mois
Oui c'est exacte. Après avoir remonté à la source, il s'avère que les iframes sont bloqués pour des raisons de sécurité depuis 2016 avec la demande #7989. Or, avec la correction de la vulnérabilité #15359, le bouclier de sécurité touche aussi désormais tous les contenus WYSIWYG. Les iframes sont donc aussi bloqués pour ces derniers.
Je peux créer une exception pour les WYSIWYG. Mais il faut bien penser que, au delà de complexifier le code, cette exception va ouvrir un pont en or à tout attaquant.
Mis à jour par Miguel Moquillon il y a environ un mois
- Statut changé de New à Feedback
Mis à jour par Miguel Moquillon il y a environ un mois
· Edité
De mon côté, je préconise plutôt de retirer la fonction iframe de la barre d'outils de CKEditor. En plus, il est fort possible que, pour des raisons de sécurité là aussi, les versions récentes de CKEditor l'ont retirés définitivement.
Mis à jour par David Lesimple il y a environ un mois
Miguel Moquillon a écrit (#note-4):
De mon côté, je préconise plutôt de retirer la fonction iframe de la barre d'outils de CKEditor. En plus, il est fort possible que, pour des raisons de sécurité là aussi, les versions récentes de CKEditor l'ont retirés définitivement.
C'est à discuter, car pas mal de clients utilisent cette possibilité.
Mis à jour par David Lesimple il y a environ un mois
David Lesimple a écrit (#note-5):
Miguel Moquillon a écrit (#note-4):
De mon côté, je préconise plutôt de retirer la fonction iframe de la barre d'outils de CKEditor. En plus, il est fort possible que, pour des raisons de sécurité là aussi, les versions récentes de CKEditor l'ont retirés définitivement.
C'est à discuter, car pas mal de clients utilisent cette possibilité.
Quel serait la solution pour afficher un ou plusieurs fichiers PDF dans un contenu wysiwyg sans passer par une iframe ?
Mis à jour par Miguel Moquillon il y a environ un mois
· Edité
Passer des PDF dans un contenu WYSIWYG est, à mon avis, une mauvaise utilisation et approche des publications. C'est en fait un détournement, d'un côté, des iframe, et de l'autre côté, un pieds de nez à la fonctionnalité de view des documents.
Les PDF devraient être joins à la publication - si elles ne le sont pas déjà à une autre publication (c'est la raison d'être d'une publication d'ailleurs), puis, dans le cas où ces documents sont à être référencés dans le contenu de la publication, ils devraient l'être par leur permalien qui permet alors au lecteur de pouvoir d'y accéder et par la fonctionnalité de view les consulter s'il le souhaite.
Sinon, une autre alternative, si le besoin le justifie (j'entends ici un vrai besoin), serait de définir un plugin CKEditor qui permet d'afficher la view de documents joints à la publication. Mais ceci relève d'un dev et donc d'une 6.5.
Mis à jour par David Lesimple il y a environ un mois
Miguel Moquillon a écrit (#note-7):
Passer des PDF dans un contenu WYSIWYG est, à mon avis, une mauvaise utilisation et approche des publications. C'est en fait un détournement, d'un côté, des iframe, et de l'autre côté, un pieds de nez à la fonctionnalité de view des documents.
Les PDF devraient être joins à la publication - si elles ne le sont pas déjà à une autre publication (c'est la raison d'être d'une publication d'ailleurs), puis, dans le cas où ces documents sont à être référencés dans le contenu de la publication, ils devraient l'être par leur permalien qui permet alors au lecteur de pouvoir d'y accéder et par la fonctionnalité de view les consulter s'il le souhaite.
Cela rajoute un clic.
D'autre part, cette sécurité est-elle justifiée quand le domaine du lien est le même que celui de l'application Silverpeas ?
Mis à jour par Miguel Moquillon il y a environ un mois
Cela rajoute un clic.
Lol. Ceci n'a aucune valeur, surtout face à la sécurité. Il y a plein de trucs où il faut plusieurs clics pour accéder à la ressource ou fonctionnalité voulue.
D'autre part, cette sécurité est-elle justifiée quand le domaine du lien est le même que celui de l'application Silverpeas ?
Non en effet. C'est une règle global. Cela signifie donc de rajouter un traitement particulier sur les iframes. Ceci peut être fait
Mis à jour par David Lesimple il y a environ un mois
· Edité
Miguel Moquillon a écrit (#note-9):
D'autre part, cette sécurité est-elle justifiée quand le domaine du lien est le même que celui de l'application Silverpeas ?
Non en effet. C'est une règle global. Cela signifie donc de rajouter un traitement particulier sur les iframes. Ceci peut être fait
L'idéal serait de pouvoir spécifier des noms de domaines dans security.properties comme pour security.web.protection.domain.allowed
Mis à jour par Miguel Moquillon il y a environ un mois
- Statut changé de Feedback à In progress...
Je vais rajouter une exception pour les iframe si le src pointe sur un hostname en HTTPS autorisés (via une propriété dans security.properties)
Mis à jour par Miguel Moquillon il y a environ un mois
- Statut changé de In progress... à Closed
Corrigé et directement porté sur les branches 6.4.x et master (pas master-jee).
Désormais, il y a une propriété dans $SILVERPEAS_HOME/properties/org/silverpeas/util/security.properties :
# When the XSS injection protection is enabled, any data sent to Silverpeas with an iframe is
# rejected unless the iframe refers, by its src attribute, an HTTPS URL whose host is among the
# allowed ones below. The Silverpeas server is always allowed, so there is no need to add it.
# Relative URLs within Silverpeas are also allowed, as long as they don't go up in the paths.
# The hosts are separated by a comma, for example: "www.youtube.com, player.vimeo.com"
security.external.iframe.hosts.allowed =
Avec ce paramètre, des serveurs externes peuvent être spécifiés et pour lesquels les iframes sont autorisés. Par défaut, le serveur Silverpeas et tout chemin relatif à Silverpeas sont autorisés, sans avoir à les expliciter.
Ainsi donc, les iframe sont autorisés désormais dans les contenus (et par conséquent contenus riches) selon les conditions ci-dessus mais attention : les iframes doivent être correctement construits et sans event-handler.