Ab v3.3.0.beta1 implementiert Discourse eine ‘strict-dynamic’ Content Security Policy (CSP). Dies eliminiert die Notwendigkeit einer manuellen CSP-Konfiguration und verbessert die Kompatibilität mit externen Tools wie Tag-Managern und Werbung erheblich.
Als Site-Administrator müssen Sie nichts unternehmen. Die Änderung wird automatisch wirksam, und alle von Ihnen verwendeten externen Skripte funktionieren weiterhin.
Für Themes sind keine Änderungen erforderlich. Eine kleine Anzahl von Plugins [1] benötigt möglicherweise eine kleine Anpassung zur Kompatibilität mit dieser Änderung (z. B. 1, 2).
Foren, die zuvor die CSP aus Kompatibilitätsgründen mit externen Skripten deaktiviert hatten, können diese nun ohne Probleme oder Konfigurationsaufwand wieder aktivieren.
Für technische Details siehe diesen Thread:
Vorerst ist es noch möglich, zum alten System zurückzukehren, indem die Website-Einstellung „content security policy strict dynamic“ deaktiviert wird. Wenn Sie dafür einen Grund haben, lassen Sie es uns bitte wissen!
Ab v3.3.0.beta3 haben wir das Schlüsselwort ‘strict-dynamic’ zu einem zwingenden Bestandteil unserer CSP gemacht. Die Website-Einstellung „content security policy strict dynamic“ wurde entfernt und die Website-Einstellung „content security policy script src“ wurde aktualisiert, um nur gültige Werte zu speichern.
Für Administratoren sollten Sie den vorherigen Wert der Website-Einstellung „content security policy script src“ in den Staff Action Logs Ihrer Website finden (https://\u003csite_url\u003e/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 - Ersetzen Sie \u003csite_url\u003e durch die Basis-URL Ihrer Website).
technisch gesehen: solche, die \u003cscript\u003e-Elemente über register_html_builder oder eine erb-Vorlage einführen ↩︎
Keine Änderung dort – Sie können immer noch 'unsafe eval' (mit Anführungszeichen) zu den Website-Einstellungen für content security script src hinzufügen.
Ich habe gesehen, dass in der Beschreibung der Einstellung content security script src angegeben ist, dass die Aktivierung von content_security_policy_strict_dynamic diese Einstellung ignoriert. Daher bin ich hier, um Rat zu suchen.
> Host-Quellen werden ignoriert, wenn content_security_policy_strict_dynamic aktiviert ist.
Der wichtige Teil dort ist „Host-Quellen“. ‚unsafe-inline‘ ist keine Host-Quelle, daher wird es weiterhin unterstützt.
Dennoch stimme ich vollkommen zu, dass dies verwirrend ist. Angesichts des Erfolgs der Einführung von strict-dynamic planen wir, das alte System zu entfernen. Sobald wir das tun, können wir alle Host-Quellen automatisch aus der Liste entfernen, und die Dinge werden für Administratoren viel einfacher sein.
Dieses neue System funktioniert vermutlich gut mit:
Inline-Skripten
Vollständigen Skriptquellen, die lokal gehostet werden
Aber was ist mit dem Fall, dass Remote-Skripte mit „loadScript“ und der vollständigen Remote-URL aufgerufen wurden?
Korrigieren Sie mich, wenn ich falsch liege, aber ich glaube nicht, dass es eine gute Möglichkeit gibt, diesen Fall zu handhaben?
Bedeutet das also, dass wir uns in diesen Fällen stattdessen darauf verlassen müssen:
die Aufrufe in ein Inline-Skript zu verschieben ODER
die vollständige Quelle als Theme-Asset herunterzuladen?
Für den ersteren Inline-Skript-Fall gibt es wohl keine Möglichkeit zu garantieren, dass das Skript geladen wird, bevor Elemente davon verwendet werden? (So wie man es innerhalb eines .then nach einem loadScript tun könnte)
strict-dynamic sollte mit Remote-Skripten funktionieren, die über loadScript geladen werden. Tatsächlich war dies der Hauptgrund für die Umstellung: Wir müssen nicht mehr jede einzelne externe Skript-URL im Voraus auflisten. Das ist besonders gut für Leute, die Werbung schalten, da diese oft eine Menge Remote-Skripte laden.
Ich habe einige Fehler gesehen, aber es liegt vielleicht nicht daran. Lassen Sie mich sehen, ob ich ein Beispiel finden kann.
Ich habe mich hauptsächlich auf ein stabiles Upgrade vorbereitet, von dem ich weiß, dass es loadScript und Remote-Skripte beinhaltet.
Können Sie mich verwöhnen und erklären, wie Remote-Skripte, die zufällig im Code mit loadScript aufgerufen werden, vom dynamischen Modus CSP „autorisiert“ werden? Passiert da Magie?
Der 'strict-dynamic'-Quellausdruck besagt, dass das Vertrauen, das einem im Markup vorhandenen Skript ausdrücklich durch die Begleitung mit einem Nonce oder Hash gegeben wird, auf alle Skripte übertragen wird, die von diesem Root-Skript geladen werden.
Solange das ursprüngliche Skript vertrauenswürdig ist (über einen Nonce), erlaubt der Browser das Laden anderer Skripte ohne Einschränkung. Und da diese Skripte vertrauenswürdig sind, können sie weitere laden!
Es gibt eine Einschränkung: Skripte dürfen nicht “parser-inserted” sein. Dies verhindert, dass strict-dynamic für XSS-Angriffe ausgenutzt wird.
Zum Beispiel wäre dies “parser-inserted” und würde blockiert werden:
Aber das programmatische Erstellen des Skriptelements beinhaltet keine HTML-Analyse, ist viel weniger wahrscheinlich ein XSS-Vektor und wird daher zugelassen:
Nein, die Nonce ist nur im ursprünglichen Skript-Tag enthalten, der von Rails gerendert wird (z. B. Core-, Plugin- oder Theme-Skripte).
Das bedeutet, dass der Core-/Plugin-/Theme-Code vertrauenswürdig ist und beliebige andere Skripte einfügen darf. Hier ist keine Nonce erforderlich – der Browser weiß, welches Skript die Einfügung vorgenommen hat, und weiß auf magische Weise, dass ihm vertraut werden kann.
