• Français
  • Déplacer tous les scripts inline dans les emplacements dédiés (CSP, XSS)

Bonjour,
Seriez vous ouvert au déplacement de tous les scripts inline dans le dossier assets ? Ceci permettrait d'avoir une CSP aux normes et un minimum efficace face à de potentielles XSS sans devoir ployer du scripting LUA ou autre.
Actuellement tous les inline vont à l'encontre des règles de bonnes pratiques par défaut renseignées dans les CSP, et donc la mise en place de cette dernière bloque toute interaction avec Rosario.

Bien cordialement.

    Bonjour Frayed0324

    Frayed0324 un minimum efficace face à de potentielles XSS

    Auriez-vous des sources indiquant que des scripts JS inline favorisent les XSS vs des scripts JS dans des fichiers qui les empêchent ?

    https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting
    Voici ce que j'ai trouvé, il y a une mention des XSS et CSP. Quant aux bonnes pratiques, contrairement à ce que vous écrivez... il est mentionné qu'avoir un onclick="doThis()" au lieu d'un évènement caché dans un fichier JS qu'il faudra retrouver... est tout simplement bien pratique.

    Cette manière de procéder est utilisée par RosarioSIS core mais aussi beaucoup de compléments.

    Par contre, peut-être que d'autres règles CSP peuvent être implémentées, comme par exemple interdire les scripts de source externe ?

    Content-Security-Policy: script-src 'self'

    Pourrait être un début ?

      francoisjacquet changed the title to Déplacer tous les scripts inline dans les emplacements dédiés (CSP).

        Je viens de vérifier, pour comparaison, aucune CSP dans l'admin de WordPress.

        Bonjour

        Les CSP de base empêchent par défaut le script inline utilisé notamment ici
        https://cwe.mitre.org/data/definitions/79.html.

        Au final chaque JS exécuté provient uniquement d'un fichier dédié au niveau du serveur, et cela permettrait d'éviter la XSS notamment présente dans la démo.

        C'est une bonne pratique au niveau sécurité pas au niveau du code (complexification) mais je pense que c'est nécessaire au regard de la criticité des données stockées.

        Au niveau modules, les inline peuvent être modifiés plus tard, mais c'était sur le principe, pour que je ne propose pas une pr pour rien si je m'y mets.

        La CSP que vous proposez et que j'ai en place effectivement empêche les scripts externes, mais ne bloquent pas les XSS locales, ce qui me préoccupe au même niveau.

        Bien cordialement

        francoisjacquet ce qui ne fait pas partie des bonnes pratiques de sécurité mais bon, vu comment WordPress a à cœur d'être troué de partout et de saper le travail de certains, ce n'est pas surprenant.

        Ah, cette XSS est en fait la possibilité d'uploader un PDF qui affiche un message d'alerte avec du texte.

        Ce n'est pas vraiment une XSS puisque lorsqu'on ouvre un PDF depuis le navigateur, on est dans une sandbox.

        J'ai eu une discussion avec VulnDB.
        Je leur ai dit que WordPress est vulnérable à cela et que ça n'a pas été rapporté, c'est donc peut-être pas une vraie XSS.
        Ils ont insisté pour dire "oui, mais c quand même une XSS, nia nia nia on est donc obligé de la rapporter".
        https://vuldb.com/?id.258911

        Frayed0324 permettrait d'éviter la XSS notamment présente dans la démo.

        Si vous avez trouvé une vraie XSS, merci de la rapporter dans une issue privée sur GitLab.

        Frayed0324 vu comment WordPress a à cœur [...] de saper le travail de certains

        Saper le travail de certains ?

          Recherche globale de <script> / <script type="text/javascript"> dans RosarioSIS et les compléments,
          Résultat :
          213 matches across 158 files

          Recherche globale de onclick=" dans RosarioSIS et les compléments,
          Résultat :
          126 matches across 87 files

          Recherche globale de onchange=" dans RosarioSIS et les compléments,
          Résultat :
          120 matches across 95 files

          Recherche globale de onsubmit=" dans RosarioSIS et les compléments,
          Résultat :
          2 matches across 2 files

          Recherche globale de onfocus=" dans RosarioSIS et les compléments,
          Résultat :
          1 match in 1 file

          D'un point de vue sécurité, la sandbox permet d'éviter plutôt une misconfiguration exceptionnelle en mode ceinture de sécurité. Ce n'est pas une couche de sécurité désignée pour rattrapper de manière automatique ces problèmes de sécurité.
          Je ne vois pas de discussion sur votre lien : est ce le bon ou est ce en privé ? Dans l'absolu le mécanisme est une XSS, même si ça n'en est pas une. C'est plutôt simplement une faille de sécurité qui peut être bloquée très facilement via une CSP basique.

          WordPress vs wpengine ou comment se mettre à dos l'entièreté de la commu open source.

          Dans l'absolu, je pense que c'est une réflexion à avoir à l'avenir dans de futurs devs, mais en attendant je vais devoir faire un lua dédié pour signer les inline.

            francoisjacquet yep j'avais déjà vu ça hier : le travail peut sembler long mais le gain en sécurité est pour moi , orienté sécurité, très significatif.

            Frayed0324 le travail peut sembler long mais le gain en sécurité est pour moi , orienté sécurité, très significatif.

            Et bien go alors :)

            Je pense qu'il vaut mieux le faire maintenant et en finir une bonne fois pour toutes avec les XSS.

              francoisjacquet perfecto.
              Souhaitez vous en faire certains ou je m'y attelle intégralement dans le core et on verra pour les modules plus tard ?
              Cordialement

                Frayed0324 vous pouvez vous y atteler intégralement pour le core s'il vous plaît.

                Je n'ai pour l'instant aucune idée de quelle serait la meilleure façon de procéder.
                Il faudrait une procédure homogène entre les modules core et les modules complémentaires (idem pour les plugins).

                Je suppose qu'il y aura des possibilités de factoriser, étant donné que beaucoup de scripts inline sont répétés.

                Enfin, s'il est possible de garder la lisibilité qu'il y avait avant, à savoir que le déplacement du script, et ce qu'il en reste, puisse indiquer tout de même quelle est l'action réalisée, ce serait super.
                Par exemple :

                onchange="ajaxPostForm(this.form);"

                Deviendrait (ceci n'est qu'un exemple) :

                data-onchange="ajax-post-form"

                Peut-être avez-vous déjà une idée précise de comment procéder ?

                  francoisjacquet changed the title to Déplacer tous les scripts inline dans les emplacements dédiés (CSP, XSS).

                    https://web.dev/articles/csp#unsafe-eval

                    Utilisation de eval() dans

                    plugins/TinyMCE_Formula/tinymce-formula/js/mathjax/MathJax.js
                    https://github.com/mathjax/MathJax/issues/1988
                    https://github.com/mathjax/MathJax/issues/256

                    Utilisation de new Function( dans

                    modules/NFC_QR_Actions/js/jszip.min.js
                    modules/Student_ID_Card/js/jszip.min.js
                    https://github.com/Stuk/jszip/issues?q=is%3Aissue+unsafe-eval (RAS, à tester)

                    Utilisation de setTimeout(" ou setInterval(" dans
                    assets/js/jscalendar/calendar.js
                    plugins/TinyMCE_Formula/tinymce-formula/js/mathjax/extensions/MathEvents.js

                    On devrait donc envisager la possibilité pour un plugin ou module de modifier la CSP si besoin (cad si l'on ne peut pas MAJ et faire sans eval() et autres).

                      À propos de CSS

                      Recherche globale de <style> dans RosarioSIS et les compléments,
                      Résultat :
                      27 matches across 25 files

                      Recherche globale de style=" dans RosarioSIS et les compléments,
                      Résultat :
                      906 matches across 297 files

                      https://stackoverflow.com/questions/30653698/csp-style-src-unsafe-inline-is-it-worth-it

                      Using a carefully crafted style rules they could send any information included on the page to external domains and expose or otherwise use that data maliciously against your users.

                      https://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html
                      La démo est assez vieille, je ne crois pas que ce soit encore d'actualité.

                      TinyMCE
                      https://www.tiny.cloud/docs/tinymce/latest/tinymce-and-csp/

                      However, TinyMCE currently requires the unsafe-inline value in the style-src directive to present content other than plain-text.

                        Bonjour,

                        Cette semaine c'est très short en termes de timing pour moi mais au moins pour l'avenir j'ai votre accord.
                        Au niveau des scripts, ce sont vraiment pour le moment les inlines qui sont préoccupants et gênants dans un premier temps car exécutés sans aucune interaction de l'utilisateur dans du contenu "externe" à l'architecture du site.

                        Les autres onclick etc sont bien moins gênants car nécessitent que soit le code serveur soit la machine cliente soient compromis en profondeur, mais le contenu n'a pas d'interactions directes et invisibles pour l'utilisateur dans le sens où c'est l'utilisateur qui va actionner le script et ce dernier aura interagit avec.

                        Le curseur est fin mais néanmoins important et ce sera plus dans un second temps que je m'y attelerai.

                          Frayed0324 je suis d'accord.

                          À noter tout de même, de ce que je comprends de la CSP, il n'y a malheureusement pas de distinction entre un <script> et un onclick.
                          Tous les 2 sont interdits si on ne spécifie pas unsafe-inline.

                            Pour les scripts inline, on peut aussi utiliser un nonce.

                            Cela évite de tout déplacer, surtout pour les scripts dynamiques qui requièrent du PHP.

                            Pour les <script> dans modules/ ou plugins/

                            Soit ils sont statiques, et peuvent être mis dans un fichier, par exemple modules/MyModule/js/MyProgram.js

                            Soit ils sont dynamiques et on utilise le nonce, par exemple <script nonce="[nonce-unique-par-requete]">
                            Le nonce étant unique par requête, cela aura pour inconvénient qu'une même page ne pourra être récupérée dans le cache...

                            Afin de factoriser, on pourra utiliser des classes comme
                            - onchange-ajax-post-form
                            - onchange-ajax-link
                            - onchange-ajax-link-append-value

                            À lire :
                            https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/