Plugin HTTPHeader

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • #31
    Bonjour,

    Sur la plupart des templates, modules, plugins, extensions, dans le code php, on a des insertions de scripts javascript ou de css.

    Par exemple, j'utilise des templates Joomspirit et j'ai, dans le fichier index.php des lignes
    Code:
    <style type="text/css">
    .... du CSS
    </style>
    Ce type de lignes passera en CSP avec une commande
    Code:
    style-src unsafe-inline
    De même, dans la plupart des modules, on retrouve des lignes <script type="text/javascript">... du code javascript ...</script> qui seront résolus par la commande script-src unsafe-inline

    Cela ne fait pas perdre le A au niveau du securityheaders.com mais, la ligne script-src unsafe-inline fait perdre le + du A+.

    Pour éviter cela, il faut
    - soit ajouter dans le plugin httpheaders des commandes SHA-256 pour chaque script signalé dans la console, mais, à chaque changement de script (mise à jour d'un module par exemple, voire même d'un paramètre), il faut vérifier que cela fonctionne toujours,
    - soit demander au développeur des modules/extensions/templates de faire la modification pour être conforme au CSP (j'ai fait la modification sur la plupart de mes modules et c'est un peu long, mais nécessaire) voir https://www.conseilgouz.com/espace-t...-days-2018-csp
    - soit vivre avec le unsafe-line.

    Pour info, je ne sais pas si tu as lu l'article https://www.joomla.fr/actualites/joo...ogle-a-chicago où il est question de "projets favorable au CSP pour prévenir les attaques XSS".

    Bon dimanche,

    Pascal
    If anything can go wrong, it will...If I can help, I will ..https://conseilgouz.com

    Commentaire


    • #32
      Bonjour.
      Pascal a tout dit.
      Bon dimanche.
      Cordialement.
      __
      Eddy !!!
      Tutoriels BreezingForms en Français : https://www.breezingforms.eddy-vh.com/

      Commentaire


      • #33
        Bonjour,

        Envoyé par pmleconte Voir le message
        Sur la plupart des templates, modules, plugins, extensions, dans le code php, on a des insertions de scripts javascript ou de css.
        En effet, quand je scrute la console, je vois, pour les lignes JS dont l'initiateur est mon domaine, des lignes appelant des plugins et des modules : GDPR, JQuery, Sigplus, MaximenuCK, et divers modules présents sur la page... Je comprends mieux, en te lisant, la corrélation, car au départ je me disais "comment peut-il y avoir du script inline alors que je n'écris jamais le moindre script moi-même ??

        Envoyé par pmleconte Voir le message
        Ce type de lignes passera en CSP avec une commande
        Code:
        style-src unsafe-inline
        C'est ce que je me suis résolue à faire, pas le choix car même en identifiant tous les sha256 de cette page, rien ne me dit qu'il n'y en a pas autant, et différents de ceux-ci, sur les 400 et quelques autres pages du site...

        Envoyé par pmleconte Voir le message
        Cela ne fait pas perdre le A au niveau du securityheaders.com mais, la ligne script-src unsafe-inline fait perdre le + du A+.
        Au-delà du seul + que cela fait perdre dans ce scan, c'est surtout le warning :
        This policy contains 'unsafe-inline' which is dangerous in the script-src directive. This policy contains 'unsafe-eval' which is dangerous in the script-src directive.
        qui me dérange, car au final je ne sais pas quel niveau de risque cela laisse sur le site.

        Tu noteras au passage que j'ai également dû laisser des unsafe-eval, ne parvenant pas non plus à être sure que j'identifierais TOUS les sha256 nécessaires à éviter ce contournement...

        Envoyé par pmleconte Voir le message
        Pour éviter cela, il faut
        - soit ajouter dans le plugin httpheaders des commandes SHA-256 pour chaque script signalé dans la console, mais, à chaque changement de script (mise à jour d'un module par exemple, voire même d'un paramètre), il faut vérifier que cela fonctionne toujours,
        C'est bien le pire : même en imaginant que j'arrive à extraire TOUS les sha256 nécessaires aujourd'hui sur TOUTES les pages du site, rien ne me dit qu'à chaque mise à jour ou changement sur le site il ne me faille pas refaire ce travail de titan...



        En tout cas, merci pour tes explications.
        Je décide d'en rester là pour l'instant, et me contenterai du A obtenu (déjà très bien sachant que j'étais en F il y a une semaine...) en attendant que les éditeurs de plugins / modules / templates se mettent à produire des contenus plus "CSP friendly".

        Bon dimanche.




        Flo, Ariège

        Il n'y a que celui qui a honte d'apprendre qui a peur de demander

        Commentaire


        • #34
          pmleconte

          - soit ajouter dans le plugin httpheaders des commandes SHA-256 pour chaque script signalé dans la console, mais, à chaque changement de script (mise à jour d'un module par exemple, voire même d'un paramètre), il faut vérifier que cela fonctionne toujours,
          Re : SHA-256
          Est-ce ce dont tu parles - la série de chiffres après jquery.min.js ?
          <script src="/media/jui/js/jquery.min.js?275f725c29082ac9346c764233b98373"></script>
          Un message d’erreur sur votre site Joomla ... ayez le reflexe de consulter lla base de connaissance : https://kb.joomla.fr

          Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez chaque jour ? Alors adhérez à l'AFUJ https://www.joomla.fr/association/adherer

          Commentaire


          • #35
            Envoyé par FlodAriege Voir le message
            ...

            Tu noteras au passage que j'ai également dû laisser des unsafe-eval, ne parvenant pas non plus à être sure que j'identifierais TOUS les sha256 nécessaires à éviter ce contournement...
            En fait, il s'agit d'un avertissement pour le unsafe-inline. Ce n'est pas trop grave, même si ce n'est pas recommandé.

            Par contre, le unsafe-eval est plus risqué car cela peut ouvrir une porte pour entrer du code dans les scripts.Il faut essayer d'en trouver l'origine pour le corriger.

            Pascal
            If anything can go wrong, it will...If I can help, I will ..https://conseilgouz.com

            Commentaire


            • #36
              Envoyé par ghazal Voir le message
              pmleconte



              Re : SHA-256
              Est-ce ce dont tu parles - la série de chiffres après jquery.min.js ?
              <script src="/media/jui/js/jquery.min.js?275f725c29082ac9346c764233b98373"></script>
              Bonjour @ghazal,

              Lorsque l'on utilise le plugin httpheader avec le CSP en mode Report-only, il donne des lignes d'erreur du style :
              Code:
               Refused to apply inline style because it violates the following Content Security Policy directive: "default-src self". Either the 'unsafe-inline' keyword, a hash ('sha256-XBktW0Mp2TfPdPHpwCZUiKf6wfiQLisX4jMSFjzNu1s='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
              Je dois t'avouer que je n'ai pas vérifié s'il s'agissait du même code mais je pense que le code que tu as correspond plutôt à un code de fichier cache, mais, là, tu me poses une colle...

              Bon dimanche,

              Pascal
              If anything can go wrong, it will...If I can help, I will ..https://conseilgouz.com

              Commentaire


              • #37
                Pascal.

                J'ai un unsafe-eval à cause de Jcomments. Sans l'instruction, le composant fonctionne mais le composant ne recharge pas après la soumission d'un commentaire, ce qui laisse penser que le comm. n'a pas été enregistré.
                As-tu une idée pour cibler et ajouter une csp précise pour éviter cet unsafe-eval ?
                Cordialement.
                __
                Eddy !!!
                Tutoriels BreezingForms en Français : https://www.breezingforms.eddy-vh.com/

                Commentaire


                • #38
                  Envoyé par pmleconte Voir le message

                  En fait, il s'agit d'un avertissement pour le unsafe-inline. Ce n'est pas trop grave, même si ce n'est pas recommandé.

                  Par contre, le unsafe-eval est plus risqué car cela peut ouvrir une porte pour entrer du code dans les scripts.Il faut essayer d'en trouver l'origine pour le corriger.

                  Pascal
                  Bonjour Pascal,

                  J'ai trouvé d'où ça vient : des boutons de partage gérés par Addthis.
                  Je ne comprends pas pourquoi, alors que mes directives autorisent déjà divers domaines addthis, il faut, en plus, ce "eval".
                  Quoi qu'il en soit : pas de unsafe-eval = pas de boutons de partage.
                  C'est pas dit que je ne finisse pas par les supprimer.
                  Mais il faut pour ça que je fasse le "deuil" du travail déjà réalisé pour dimensionner des images au format twitter-card, des textes saisis pour les RS, etc...

                  Dans Report URI, je lis ceci pour les 3 eval rencontrés :

                  Code:
                  "csp-report": {
                          "document-uri": "https://www.mondomaine.fr/titre-article.html",
                          "effective-directive": "script-src",
                          "original-policy": "default-src 'self'; report-uri https://mondomaine.report-uri.com/r/d/csp/reportOnly",
                          "blocked-uri": "eval",
                          "line-number": 2,
                          "column-number": 124863,
                          "source-file": "https://s7.addthis.com"
                  Pourquoi diable, alors que mes CSP autorisent
                  Code:
                  *addthis.com
                  faut-il en plus autoriser ces "eval" ?

                  Et surtout, existe-t-il un moyen de les autoriser en les ciblant mieux qu'avec un 'unsafe-eval' ? En fait, je pensais que j'allais trouver des sha256 ou quelque chose d'équivalent, mais pas du tout. Il n’apparaît rien d'exploitable dans la console dans cet objectif...

                  Merci.


                  Ah ! J'allais oublier !!
                  Pour toutes les directives pour lesquelles je n'ai obtenu aucun résultat dans le rapport généré sur Report URI, je n'avais rien fait.
                  Alors, pour tout ça :
                  child-src : 0 résultat
                  default-src : 0 résultat
                  manifest-src : 0 résultat
                  media-src : 0 résultat
                  object-src : 0 résultat
                  worker-src : 0 résultat

                  ... j'ai ajouté, en dernier lieu, un :
                  default-src 'self'
                  J'ai bien fait ?


                  Et, en lisant le rapport d'analyse Dareboost, j'ai appris aussi que :
                  Votre page contient des liens relatifs. Pour transformer ces liens relatifs en URLs complètes, le navigateur se basera sur la valeur de votre élément <base>.
                  En cas d’attaque de type XSS (Cross-Site Scripting), un attaquant pourrait modifier la valeur de l’attribut href de votre <base> dans l’optique de détourner une partie de votre trafic vers un autre site web. Définissez une politique de sécurité limitant les domaines possibles dans les valeurs d’un élément <base>.
                  Du coup, j'ai ajouté une règle :
                  base-uri 'self'

                  Reste encore à savoir quoi faire avec :
                  plugin-types : 0 résultat
                  form-action : 0 résultat
                  frame-ancestors : 0 résultat
                  navigate-to : 0 résultat
                  block-all-mixed-content : 0 résultat
                  upgrade-insecure-requests : 0 résultat
                  require-sri-for : 0 résultat
                  unknown : 0 résultat
                  ... liste parmi laquelle celui qui m'interroge le plus, c'est le form-action : que faut-il mettre comme règle ? 'self' ??
                  Dernière édition par FlodAriege à 05/05/2019, 17h48
                  Flo, Ariège

                  Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                  Commentaire


                  • #39
                    Envoyé par Eddy.vh Voir le message
                    Pascal.

                    J'ai un unsafe-eval à cause de Jcomments. Sans l'instruction, le composant fonctionne mais le composant ne recharge pas après la soumission d'un commentaire, ce qui laisse penser que le comm. n'a pas été enregistré.
                    As-tu une idée pour cibler et ajouter une csp précise pour éviter cet unsafe-eval ?
                    Je n'avais pas vu ce unsafe-eval pour JComments.

                    Il vient du fichier jcomments.js à cause de l'utilisation de la classe Math qui est considérée par CSP à l'identique que eval.

                    Je n'ai pas trouvé de paramètre sauf à modifier le composant JComments

                    Pascal
                    If anything can go wrong, it will...If I can help, I will ..https://conseilgouz.com

                    Commentaire


                    • #40
                      Envoyé par pmleconte Voir le message

                      Je n'avais pas vu ce unsafe-eval pour JComments.

                      Il vient du fichier jcomments.js à cause de l'utilisation de la classe Math qui est considérée par CSP à l'identique que eval.

                      Je n'ai pas trouvé de paramètre sauf à modifier le composant JComments

                      Pascal
                      Merci pour ton retour.
                      Je sais que daneel avait bosse sur Jcomments mais il la pas encore fait de retour.

                      Flo.
                      Le default-src doit, je pense, se trouver en tête de liste.
                      Tu peux le glisser en haut de la pile dans le plugin.

                      Quand tu n'as plus d'erreurs, il est inutile d'ajouter d'autres règles.
                      Cordialement.
                      __
                      Eddy !!!
                      Tutoriels BreezingForms en Français : https://www.breezingforms.eddy-vh.com/

                      Commentaire


                      • #41
                        Après quelques tests complémentaires, ce n'est pas la classe Math qui coince, mais le setTimeout suivi de texte (voir https://stackoverflow.com/questions/...-in-firefox-os). Donc la correction pourra venir de la modification de la fonction fade (ligne 295 du jcomments.js) qui est le seul endroit où setTimeout est suivi de texte.

                        Il faut remplacer le texte par un appel à une "function"

                        Pascal

                        If anything can go wrong, it will...If I can help, I will ..https://conseilgouz.com

                        Commentaire


                        • #42
                          Donc, pour essayer, j'ai remplacé la fameuse ligne 295 du fichier jcomments-v2.3.js avec
                          Code:
                          fade: function(id,s,e,m){var speed=Math.round(m/100),timer=0;if(s>e){for(var i=s;i>=e;i--){setTimeout(function() {JComments.prototype.setOpacity('"+id+"',"+i+")},(timer*speed));timer++;}var o=JComments.prototype.$(id);if(o){setTimeout(function(){o.style.display='none';},((s-e)*speed));}}else if(s<e){for(var i=s;i<=e;i++){setTimeout(function(){JComments.prototype.setOpacity('"+id+"',"+i+")},(timer*speed));timer++;}}},
                          Et, en supprimant le unsafe-eval de mon CSP, cela semble fonctionner correctement, même si le fade me semble un peu trop rapide.

                          Pascal
                          If anything can go wrong, it will...If I can help, I will ..https://conseilgouz.com

                          Commentaire


                          • #43
                            Merci Pascal. Je teste au plus vite.
                            Cordialement.
                            __
                            Eddy !!!
                            Tutoriels BreezingForms en Français : https://www.breezingforms.eddy-vh.com/

                            Commentaire


                            • #44
                              Envoyé par Eddy.vh Voir le message

                              Flo.
                              Le default-src doit, je pense, se trouver en tête de liste.
                              Tu peux le glisser en haut de la pile dans le plugin.

                              Quand tu n'as plus d'erreurs, il est inutile d'ajouter d'autres règles.
                              Je peux glisser les "modules" contenant les règles mais... ils ne changent pas d'ordre. Ils glissent, mais dès que je les relâche, ils reviennent à leur position initiale...
                              Si j'y pense, je referai la saisie dans l'ordre.

                              Le default-src couvre les trucs-src, mais pas, par exemple, le base-uri. Je lis aussi, notamment sur Dareboost, qu'il faudrait bannir les frame-ancestors (avec un 'none'). Quant aux autres directives, il faudrait que j'aille un peu plus loin dans mes lectures pour savoir...

                              Merci à tous pour votre aide !
                              @ +
                              Flo, Ariège

                              Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                              Commentaire


                              • #45
                                Une chose à garder à l'esprit aussi est que la sécurité à 100 % n'existe pas. Si quelqu'un VEUT rentrer chez vous, il finira toujours pas y arriver. Heureusement, dans 99,99% des cas, les pirates ne veulent pas entrer CHEZ VOUS, mais là où c'est (assez) facile. Le but est donc de leur rendre la tâche aussi compliquée que possible, sans rendre son propre travail et son propre usage du site inutilement compliqué.

                                En théorie, oui, un "unsafe-inline" n'est pas une bonne chose, mais s'il y a un réellement un script malveillant sur votre serveur qui utilise "eval", c'est qu'un pirate a eu accès à celui-ci et, donc, les problèmes sont beaucoup plus sérieux parce que s'il a accès aux fichiers, il peut très bien modifier votre fichier .htaccess pour en changer les règles. Ce serait différent si la CSP était activé au niveau du serveur lui-même (c'est ce que je fais pour mes clients), mais si elle est dans un fichier à la racine du site ...

                                En résumé, une note "A" est suffisante avec une autorisation pour les sites extérieurs admis, et puis, une bonne protection du serveur lui-même : accès au fichiers en SFTP seulement, chager le mot de passe régulièrement, protéger la console d'hébergement, ....
                                Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
                                Administrateur certifié Joomla! 3
                                https://www.betterweb.fr

                                Commentaire

                                Annonce

                                Réduire
                                Aucune annonce pour le moment.

                                Partenaire de l'association

                                Réduire

                                Hébergeur Web PlanetHoster
                                Travaille ...
                                X