WikiNi permet actuellement à quiconque d'utiliser du code HTML dans chaque page.
Pour cela, il suffit de mettre le code HTML entre deux paires de guillemets doubles.
Cette possibilité comporte des risques et des effets génants que nous allons étudier.
Effets génants
Ces effets ne remettent pas en cause le fonctionnement et la pérennité de l'application, mais occasionnent diverses gènes.
- texte dont la police est très grande : par exemple : <p style="font-size: 9999px">test de phrase</p>
- image dont la taille est très grande : par exemple : <img src="http://www.geneanet.org/pics/commun/logo.gif" width="13220" height="14300">
- import d'une feuille de style externe : par exemple : <style type="text/css" media="all"> @import "http://charles.nepote.free.fr/wakkafr/wakka.css";</style>
- Ne peut-on jouer avec l'attribut !important ou une autre technique (?) pour éviter cela ?
- certains navigateurs pourraient mal gérer la fermeture intempestive de certaines balises : par exemple : </body></html>
- Les balises fermées données en exemple, n'ont aucun effet sur Mozilla 1.1 et Internet Explorer 5.0.
- d'une manière générale, du code qui n'est pas valide : un code non valide risque des effets visuels génant.
- [Je me permets d'insérer mon commentaire ici. En soi pouvoir importer une feuille de style externe ne représente pas à mes yeux un problème. Il appartient à l'auteur de décider s'il veut être lisible ou non. A partir de là, lui laisser la possibilité d'user de styles supplémentaires n'est pas nécessairement un mal. Et je déconseille vivement de jouer avec l'attribut "important!"; il est utilisé par les utilisateurs quand ils ne veulent pas ou ne peuvent pas lire certaines choses; les malvoyants, notamment, utilisent des feuilles de styles avec des attributs "important!" pour lire en gros les pages qu'ils lisent.
- Par contre, il est parfaitement exact que cela pose un problème énorme de conformité aux standards, ainsi qu'un grave problème de sécurité.
--
GiJo]
Risques pour l'intégrité de l'application
Certains codes malicieux pourraient en revanche menacer l'intégrité même de l'application.
- D'après Éric Daspet, une "image tout court, ça peut être un probleme avec certains sites qui mettent le numéro de session dans l'url et les navigateurs qui renvoient cette même url en referer lors du contact avec le serveur contenant l'image. Pour peu qu'il y ai une identification avec la session en question...". Ce problème semble cependant lié à la façon dont l'application a été faite, non à l'image en elle-même. Dans les "referers" de http://www.wikini.net/, on trouve des choses du genre : http://www.wikini.net/wakka.php?PHPSESSID=2e26b8c783c58b5c18d1a471bc5fb66c&wiki=RechercheTexte&phrase=rss. Je ne suis pas un spécialiste de la question, est-ce un trou de sécurité ? Comment l'exploiter ?
- Toute forme de JavaScript. Le JavaScript peut menacer concrètement l'application sous diverses formes :
- menace liée au piratage "technique" de l'identité d'un utilisateur : Éric Daspet mentionne l'exemple d'un "javascript inséré qui récupere les cookies (dont celui de la session d'authentification)"
- menace liée au piratage "social" de l'identité d'un utilisateur : un JavaScript redirige l'utilisateur vers une page d'un autre site, lui demandant de s'identifier à nouveau.
Solutions à ces problèmes
La question de fond, c'est peut-être : est-ce qu'il faut filtrer le code dangereux ou laisser uniquement (principe de précaution) le code a priori sans danger...
Au moins peut-on mettre en oeuvre quelques règles simples limitant les problèmes :
- filtrage du JavaScript
- filtrage de l'attribut HTML "style" ?
- filtrage des balises HTML "style" et "link" ?
Je me pose la question s'il ne faut carrément pas supprimer l'utilisation de html ?
L'utilisation actuelle du double " étant :
- l'affichage sans formatage
- l'appel des fonctions pour un formatage xml.
--
DavidDelon
- Je pense pas que cela soit une bonne idée de supprimer l'utilisation du html. En effet, à l'heure actuelle les régles de formatage pour les tableaux ne sont pas implémentées. L’utilisation du html permet de résoudre le problème. Il faudrait seulement filter le code a priori dangereux.
- .-- JeanPascalMilcent
- Le formatage des tableaux n'est pas implementé, mais ce n'est pas très difficile à faire. Le principal problème étant de se mettre d'accord sur une syntaxe. J'ai écrit une implémentation de tableau dans WikiNi pour un besoin personnel cela m'a pris une journée. --GarfieldFr
- Voici comment SPIP implémente les tableaux afin que la syntaxe soit simple pour l'utilisateur:
-
- | {{Nom}} | {{Prénom}} | {{Age}} |
- | Marso | Ben | 23 ans |
- | Capitaine | | non connu |
- | Philant | Philippe | 46 ans |
- | Cadoc | Bébé | 4 mois |
- Il suffit de mettre des barres qu'interprete SPIP afin de restituer un tableau dans l'article qui contient ce code (les accolades servent à mettre un texte en gras afin de faire le titre, si on voulait faire la meme chose sur WikiNi il suffirait de mettre des **) C'est simple à l'utilisation et j'imagine à la conception du code php qui le traite--PatriceLegoux
Je pense aussi qu'il faut filtrer le code dangereux. Dans un premier temps je pense qu'il serait préférable de suivre l'idée de
DavidDelon et de supprimer l'utilisation du html dans
WiKini --
PatrickPaul
Réalisations
- Le moteur de Wiki utilisé pour Wikipédia ne laisse passer que le code a priori sans danger : voir la fonction removeHTMLtags ( $s ) qu'ils ont développé (ici la version "Phase III").
- Simon Willison a réalisé une classe PHP [en] pour gérer du XHTML dans les commentaires de son Weblog. Il détaille ce qu'elle permet et ce qu'elle ne permet pas.
Références
Le CERT a publié 3 bulletins d'alerte relatifs à ce type de problème :
Exemple
Exemple de risque si on autorise le HTML dans une page :
ExempleHTMLPourLUtilisateur
Cette page est une page
WikiNi normale avec un petit bout de code "méchant" dedans (juste une redirection mais ca pourrait être pire). Maintenant imaginons que ce bout de code soit sur la
PagePrincipale .... et le site devient inaccessible !!! --
GarfieldFr
Modifier la page ExempleHTMLPourLUtilisateur