Content-Security-Policy utilise désormais 'strict-dynamic'

Annonces
1

À partir de v3.3.0.beta1, Discourse implémente une politique de sécurité de contenu (CSP) ‘strict-dynamic’. Cela éliminera le besoin de configuration manuelle de la CSP et améliorera considérablement la compatibilité avec les outils externes tels que les gestionnaires de balises et la publicité.

En tant qu’administrateur de site, vous n’avez rien à faire. Le changement prendra effet automatiquement, et tous les scripts externes que vous utilisez continueront de fonctionner.

Aucune modification n’est requise pour les thèmes. Un petit nombre de plugins [^1] pourrait nécessiter une petite modification pour la compatibilité avec ce changement (par exemple, 1, 2).

[^1] : techniquement : ceux qui introduisent des éléments <script> via register_html_builder ou un modèle erb

Les forums qui avaient précédemment désactivé la CSP pour la compatibilité avec des scripts externes devraient maintenant pouvoir la réactiver sans aucun problème ni effort de configuration.

Pour les détails techniques, consultez ce sujet :

Pour l’instant, il est toujours possible de revenir à l’ancien système en désactivant le paramètre de site « content security policy strict dynamic ». Si vous avez une raison de le faire, veuillez nous en informer !

À partir de v3.3.0.beta3, nous avons rendu le mot-clé ‘strict-dynamic’ une partie obligatoire de notre CSP. Le paramètre de site « content security policy strict dynamic » a été supprimé et le paramètre de site « content security policy script src » a été mis à jour pour ne stocker que des valeurs valides.

Pour les administrateurs, vous devriez pouvoir trouver la valeur précédente du paramètre de site « content security policy script src » dans les journaux d’actions du personnel de votre site (https://<URL_du_site>/admin/logs/staff_action_logs?filters=%7B%22action_name%22%3A%22change_site_setting%22%2C%22action_id%22%3A3%2C%22subject%22%3A%22content_security_policy_script_src%22%7D - Remplacez <URL_du_site> par l’URL de base de votre site).

26 « J'aime »
2

Comment puis-je configurer 'unsafe-eval' après cette modification comme avant ?

1 « J'aime »
3

Aucun changement ici - vous pouvez toujours ajouter ‘unsafe eval’ (avec les guillemets) au paramètre du site content security script src.

3 « J'aime »
4

J’ai vu que la description du paramètre content security script src indique que l’activation de content_security_policy_strict_dynamic ignorera ce paramètre, je suis donc venu ici pour consulter.

3 « J'aime »
5

La description indique

> Les sources d’hôtes seront ignorées lorsque content_security_policy_strict_dynamic est activé.

Le point important est « Sources d’hôtes ». ‘unsafe-inline’ n’est pas une source d’hôte, il est donc toujours pris en charge.

Cela dit, je suis tout à fait d’accord pour dire que c’est déroutant. Compte tenu du succès du déploiement de strict-dynamic, nous prévoyons de supprimer l’ancien système. Une fois que nous aurons fait cela, nous pourrons supprimer automatiquement toutes les sources d’hôtes de la liste, et les choses seront beaucoup plus simples pour les administrateurs. :rocket:

5 « J'aime »
6

OK, merci pour la clarification.

4 « J'aime »
7

David,

Juste quelques éclaircissements.

Ce nouveau système fonctionne donc probablement bien avec :

  • les scripts intégrés
  • les sources de scripts complètes hébergées localement

Mais qu’en est-il du cas où des scripts distants ont été invoqués avec « loadScript » et l’URL distante complète ?

Corrigez-moi si je me trompe, mais je ne pense pas qu’il existe un moyen élégant de gérer ce cas ?

Cela signifie-t-il donc que pour ces cas, nous devons plutôt nous fier à :

  • déplacer cette invocation vers un script intégré OU
  • télécharger la source complète en tant qu’atout de thème ?

Pour le premier cas de script intégré, je suppose qu’il n’y a aucun moyen de garantir que le script est chargé avant d’utiliser des éléments de celui-ci ? (Comme vous pourriez le faire dans un .then après un loadScript)

2 « J'aime »
8

strict-dynamic devrait fonctionner avec des scripts distants chargés via loadScript. En fait, c’était la raison principale du changement : nous n’avons plus besoin de lister toutes les URL de scripts externes à l’avance. C’est particulièrement bénéfique pour les personnes qui diffusent des publicités, lesquelles font souvent appel à une multitude de scripts distants.

Rencontrez-vous des erreurs avec loadScript ?

3 « J'aime »
9

Je rencontrais des erreurs, mais ce n’est peut-être pas pour cette raison. Laissez-moi voir si je peux trouver un exemple.

Je me préparais principalement à une mise à niveau stable qui, je le sais, implique loadScript et des scripts distants.

Pouvez-vous me faire plaisir et m’expliquer comment les scripts distants qui sont invoqués aléatoirement dans le code avec loadScript finissent par être « autorisés » par le CSP en mode dynamique ? Y a-t-il de la magie à l’œuvre ?

3 « J'aime »
10

Oui !

MDN propose une bonne explication et des exemples.

L’expression source 'strict-dynamic' spécifie que la confiance explicitement accordée à un script présent dans le balisage, en l’accompagnant d’un nonce ou d’un hash, sera propagée à tous les scripts chargés par ce script racine.

Donc, tant que le script d’origine est approuvé (via un nonce), le navigateur lui permet de charger d’autres scripts sans restriction. Et ensuite, comme ces scripts sont approuvés, ils peuvent en charger d’autres !

Il y a une mise en garde : les scripts ne peuvent pas être “insérés par l’analyseur”. Cela empêche l’exploitation de strict-dynamic pour des attaques XSS.

Donc, par exemple, ceci serait “inséré par l’analyseur” et serait bloqué :

document.head.appendChild("<script src='https://example.com/xss-attempt.js' />");

Mais la construction de l’élément script par programmation n’implique pas d’analyse HTML, est beaucoup moins susceptible d’être un vecteur XSS, et est donc autorisée :

const script = document.createElement("script");
script.src = "https://example.com/script.js"
document.head.appendChild(script);

^^ c’est essentiellement ainsi que fonctionne loadScript()

3 « J'aime »
11

Excellent lien.

OK, j’y suis presque, merci !

Le nonce est-il également inclus dans les balises script rendues par loadScript ?

2 « J'aime »
12

Non, le nonce n’est inclus que sur la balise de script d’origine rendue par Rails (par exemple, les scripts de base, de plugin ou de thème).

Cela signifie que le code de base/plugin/thème est approuvé et est autorisé à insérer d’autres scripts. Aucun nonce requis ici - le navigateur sait quel script a effectué l’insertion et sait magiquement qu’il peut être approuvé.

4 « J'aime »
13

David, encore une fois, merci pour votre temps !

4 « J'aime »
14

6 messages ont été déplacées vers un nouveau sujet : Erreur CSP lors de l’ajout d’un script via un composant de thème