IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

Controleur de framework : autoriser les contenus HTML


Sujet :

Langage PHP

  1. #1
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2014
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2014
    Messages : 3
    Points : 2
    Points
    2
    Par défaut 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.

  2. #2
    Expert éminent sénior
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    Mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 142
    Points : 16 545
    Points
    16 545
    Billets dans le blog
    12
    Par défaut
    Salut,

    Citation Envoyé par Sbebastien Voir le message
    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 Voir le message
    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 Voir le message
    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

  3. #3
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2014
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2014
    Messages : 3
    Points : 2
    Points
    2
    Par défaut
    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.

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 691
    Points : 20 222
    Points
    20 222
    Par défaut
    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 ?
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    101
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 101
    Points : 144
    Points
    144
    Par défaut
    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.

  6. #6
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2014
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2014
    Messages : 3
    Points : 2
    Points
    2
    Par défaut
    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é.

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

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

    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.

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


    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)

Discussions similaires

  1. Réponses: 6
    Dernier message: 17/11/2005, 14h39
  2. Script pour enlever les balises html
    Par Scratch48 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 4
    Dernier message: 02/11/2005, 17h16
  3. [XSL] conserver les balises html
    Par krappa dans le forum XSL/XSLT/XPATH
    Réponses: 2
    Dernier message: 07/07/2005, 15h14
  4. forcer xsl à interpréter les balises html
    Par canal68 dans le forum XSL/XSLT/XPATH
    Réponses: 2
    Dernier message: 07/07/2005, 15h02
  5. comment autoriser les reférences croissée ??
    Par champion dans le forum PostgreSQL
    Réponses: 2
    Dernier message: 13/09/2004, 10h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo