Controleur de framework : autoriser les contenus HTML

Version imprimable

26/07/2014, 15h39
Sbebastien

Controleur de framework : autoriser les contenus HTML
Bonjour,

Je recherche l'expérience d'autres développeurs afin d'élucider l'un de mes problèmes.

J'ai développé un framework dont la méthode de vue convertit tout caractère HTML en entitées (prévention de failles XSS sur les contenus).
L'enrichissement des contenus était alors géré en markdown, et traité par la suite.

Or je me suis retrouvé face à un cas où j'ai du retirer (dans l'instance du framework uniquement) cette fonction de traitement. Et la question que je me pose aujourd'hui est de savoir si elle ne devrait pas être retirée. A savoir que ceci m'exposerait à plusieurs problématiques :
- Rétrocompatibilité : tout site dont la version du framework sera mis à jour à l'avenir devra être revu afin d'appeler la fonction de traitement des données en amont de la méthode du contrôleur
- Erreur humaine : Ayant prit l'habitude que ce traitement de sécurité sois automatiquement appliqué, il pourrait m'arriver, ainsi qu'aux utilisateurs du framework, d'oublier de sécuriser la sortie HTML des contenus.
Pour avoir travaillé en agence, la plupart des outils que j'ai pu utiliser ont toujours nécessité l'appel d'une fonction de traitement en amont de l'appel de la vue.
Je me suis cependant demandé pourquoi ceci n'était pas inclus dans l'intégration des données dans la vue, puisque 99.99% des contenus de sites n'utilisaient pas le HTML pour l'enrichissement.

Je fais donc appel à vous afin d'obtenir vos retours d'expérience sur la question :
- Autorisez-vous la transmission de code HTML de contenus ?
- Préférez-vous le traitement systématique ou l'appel d'une fonction en amont ?
- Un conseil à me donner sur le sujet ?
Il est à savoir que j'envisage également d'ajouter un paramètre dans la méthode afin d'autoriser le HTML dans des cas particuliers, mais j'attends avec impatience vos retours pour cette décision.

En vous remerciant d'avance,

P.S : Si ce sujet manque de clarté, n'hésitez pas à me le faire savoir, je n'ai pas posté de messages dans un forum depuis un moment.
26/07/2014, 20h09
rawsrc

Salut,

Citation:

Envoyé par Sbebastien

Autorisez-vous la transmission de code HTML de contenus ?

Généralement non, sauf quelques cas où le code HTML est très très limité, je préfère sinon passer par du BBCode ainsi au rendu j'échappe tout sans me poser de question et je transforme que le BBCode valide en HTML.

Citation:

Envoyé par Sbebastien

Préférez-vous le traitement systématique ou l'appel d'une fonction en amont ?

Traitement systématique uniquement dans la vue, ailleurs rien du tout. L'expérience et les bonne pratiques prévalent.
Absolument toutes les données reçues sont validées une par une et dans la mesure du possible typée, tous les paramètres des fonctions sont typés (toujours dans la limite du possible : array, interface, class...)
Pour ce qui est de la vue : le petit moteur de template que je me suis codé, échappe absolument tout sauf demande écrite expresse et autorisation du chef voire de sa mère ;)

Citation:

Envoyé par Sbebastien

Un conseil à me donner sur le sujet ?

Personnellement, je conseille d'éviter l'altération des données en base par des fonctions d'échappement du rendu (clairement, j'évite les htmlspecialchars() htmlentities() en guise de protection des données). J'ai trop dégusté les fois où il a fallu attaquer les données sans avoir à disposition les fonctions inverses correspondantes... Rien que la tables des htmlentities à inverser à la main est une horreur.

Bref, rien d'extraordinaire. La routine, maintenant :ccool:
26/07/2014, 23h38
Sbebastien

Merci de ta réponse.

Je voulais m'assurer que 5 releases de mon framework ne posaient pas trop de problèmes.
Je vais cependant implémenter cette option permettant d'autoriser un contenu HTML de source sûre (ou cas où).

Merci encore de ton aide.
28/07/2014, 08h56
grunk

Avoir une vue qui échappe automatiquement le contenu qu'elle affiche, c'est du confort. J'aime bien quand c'est possible , mais il faut aussi pouvoir le désactiver.
Le titre de ton message laisse supposer que tu t'occupe de celà dans le contrôleur , ce qui est une erreur de conception.
C'est ta vue qui doit gérer ça, avec par exemple un paramètre d'instanciation.

Comme l'a très bien dit rawsrc , pas d'échappement à l'insertion dans la base , mais à l'affichage. C'est certes un chouilla plus consommateur de ressources , mais c'est rien du tout par rapport à l'emmerdement de traiter des données non brutes.

Avec twig (moteur de template) l'échappement est automatique et si tu as besoin d'autoriser du code html tu insère tes variables dans un bloc spécial. C'est à mon sens la méthode à suivre.

C'est open source ton framework ? on peut voir ?
28/07/2014, 11h11
Yellu

Bonjour,

Ayant également développé un framework, je me permet de donner mon avis.
Je suis contre le fait que le passage de variable à la vue htmlencode les données à la volée et même si cela est court-circuitable par un paramètre de la méthode.
Ceci pour 2 raisons :

1) La vue dispose également de chose qu'il faut htmlencoder et qui ne sont pas transmisent via le controlleur, un entête de tableau, un gros titre h1, etc...
Le développeur va se retrouver à devoir trier ce qui a déjà été encodé et ce qui ne l'est pas encore. A mon sens il y aura donc un risque de double encodage dans la vue.

2) Cela lie le format HTML au mécanisme de vue. Une vue pourrait très bien être une génération CSV, ou texte brute qui ne nécessite pas la notion de htmlencodage.

Je préfère donc que tous les encodages soit fait dans la vue et non au moment du passage de variable par le controlleur.

Bonjour,

Merci de vos témoignages.

J'ai mis à a jour le framework à ce sujet pour permettre d'outre passer l'échappement automatique sans avoir de souci de rétrocompabilité.

Citation:

Avoir une vue qui échappe automatiquement le contenu qu'elle affiche, c'est du confort. J'aime bien quand c'est possible , mais il faut aussi pouvoir le désactiver.
Le titre de ton message laisse supposer que tu t'occupe de celà dans le contrôleur , ce qui est une erreur de conception.
C'est ta vue qui doit gérer ça, avec par exemple un paramètre d'instanciation.

J'admet que le sujet n'est pas explicitement clair au vu de la conception du framework. Voici un petit exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 <?php class ControlerName { // Reponse classique public function defaultAction() { // Assignation des données Response::assign(array(...)) // Définition de la vue au format HTML // Cette méthode se charge d'encoder les données précédement fournies Response::view('template-name'); /* D'autres types de réponses peuvent être envoyés : Response::xml(); Response::json(); ... Note : seule la dernière réponse est prise en compte à la sortie. Les méthodes de la classe Response se chargent d'envoyer le contenu et les en-têtes ainsi que de la gestion du cache. */ } // Réponse sans encodage global des données public function OtherAction { /* On ne passe plus ici par la classe Response Mais directement par la classe View qui est également utilisée par la méthode Response::view() Pour simplifier : on reconstruit la méthode Response::view() en retirant l'encodage des données. Usage : View::parse($template, $data = array(), $encode = true); */ $data = array( 'title' => entitieschars('...'), // Ce contenu est encodé 'content' => '<p>...</p>', // celui-ci ne l'est pas ); View::parse('template-name', array(...), false); /* Pour reproduire plus précisemment la méthode Response::view, il faudrait gérer les envoies d'en-têtes avec Response::headers(array(...)); et l'usage de la class Cache disponible depuis la dernière release. */ } } ?>
L'exemple ci-dessus est des plus basiques, mais il me permet d'illustrer mes propos :
- La classe Response gère la vue
- la classe View gère le parsage template/données

Cette façon de procéder peut paraître étrange vis à vis du modèle MVC, mais je précise que le framework a été conçu pour répondre à des besoins précis.

Citation:

1) La vue dispose également de chose qu'il faut htmlencoder et qui ne sont pas transmisent via le controlleur, un entête de tableau, un gros titre h1, etc...
Le développeur va se retrouver à devoir trier ce qui a déjà été encodé et ce qui ne l'est pas encore. A mon sens il y aura donc un risque de double encodage dans la vue.

Citation:

Avec twig (moteur de template) l'échappement est automatique et si tu as besoin d'autoriser du code html tu insère tes variables dans un bloc spécial. C'est à mon sens la méthode à suivre.

Ce cas peut être gérér à l'aide de la seconde méthode de mon exemple. Certes cela demande quelques lignes de code en plus, mais si la plupart des données utilisent un enrichissement en markdown/BBCode/..., c'est amplement suffisant.

Citation:

2) Cela lie le format HTML au mécanisme de vue. Une vue pourrait très bien être une génération CSV, ou texte brute qui ne nécessite pas la notion de htmlencodage.

Passant par des méthodes différentes selon la réponse à transmettre au navigateur, l'encodage n'est systématique que sur la méthode de vues HTML.

Citation:

Comme l'a très bien dit rawsrc , pas d'échappement à l'insertion dans la base , mais à l'affichage. C'est certes un chouilla plus consommateur de ressources , mais c'est rien du tout par rapport à l'emmerdement de traiter des données non brutes.

Le framework compense la consommation de ressources supplémentaires à l'aide du système de cache intégré (facultatif, géré par la méthode Response::cache()), donc pas de soucis à ce niveau là.

Citation:

C'est open source ton framework ? on peut voir ?

Il l'est ! https://github.com/graphidev/WOK
Le WIKI n'est par contre pas à jour et je travaille sur une nouvelle doc. À défaut, un générateur de doc peut être utilisé sur le code source.

En espérant avoir été plus précis.

Je suis également ouvert à toute suggestion sur le framework (en MP pour éviter le hors sujet)