Da v3.3.0.beta1, Discourse implementa una Content Security Policy (CSP) ‘strict-dynamic’. Questo eliminerà la necessità di configurazioni CSP manuali e migliorerà notevolmente la compatibilità con strumenti esterni come tag manager e pubblicità.
In qualità di amministratore del sito, non è necessario fare nulla. La modifica avrà effetto automaticamente e gli script esterni che stai utilizzando continueranno a funzionare.
Non sono richieste modifiche per i temi. Un piccolo numero di plugin [1] potrebbe necessitare di una piccola modifica per la compatibilità con questa modifica (ad esempio, 1, 2).
I forum che in precedenza avevano disabilitato la CSP per compatibilità con script esterni dovrebbero ora essere in grado di riattivarla senza problemi o sforzi di configurazione.
Per i dettagli tecnici, consulta questo argomento:
Per ora, è ancora possibile tornare al vecchio sistema disabilitando l’impostazione del sito ‘content security policy strict dynamic’. Se hai qualche motivo per farlo, faccelo sapere!
Da v3.3.0.beta3, abbiamo reso la parola chiave ‘strict-dynamic’ una parte obbligatoria della nostra CSP. L’impostazione del sito ‘content security policy strict dynamic’ è stata rimossa e l’impostazione del sito ‘content security policy script src’ è stata aggiornata per memorizzare solo valori validi.
Per gli amministratori, dovresti essere in grado di trovare il valore precedente dell’impostazione del sito ‘content security policy script src’ dai log delle azioni dello staff del tuo sito (https://<URL_DEL_TUO_SITO>/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 - Sostituisci <URL_DEL_TUO_SITO> con l’URL di base del tuo sito).
tecnicamente: quelli che introducono elementi <script> tramite register_html_builder o un template erb↩︎
Ho visto che la descrizione dell’impostazione content security script src afferma che l’abilitazione di content_security_policy_strict_dynamic ignorerà questa impostazione, quindi sono venuto qui per consultare.
Le origini host verranno ignorate quando content_security_policy_strict_dynamic è abilitato.
La parte importante lì è “origini host”. ‘unsafe-inline’ non è un’origine host, quindi è ancora supportato.
Detto questo, sono totalmente d’accordo che questo sia confuso. Dato il successo del rollout di strict-dynamic, abbiamo in programma di rimuovere il vecchio sistema. Una volta fatto ciò, potremo rimuovere automaticamente tutte le origini host dall’elenco e le cose saranno molto più semplici per gli amministratori.
Questo nuovo sistema presumibilmente funziona bene con:
script inline
sorgenti di script complete ospitate localmente
Ma che dire del caso in cui gli script remoti sono stati richiamati con “loadScript” e l’URL remoto completo?
Correggimi se sbaglio, ma non credo ci sia un modo carino per gestire quel caso?
Quindi, significa che per quei casi dobbiamo invece fare affidamento su:
spostare tale invocazione in uno script inline OPPURE
scaricare l’intera sorgente come risorsa del tema?
Per il primo caso di script inline, immagino non ci sia modo di garantire che lo script venga caricato prima di utilizzarne gli elementi? (Come potresti fare all’interno di un .then dopo un loadScript)
strict-dynamic dovrebbe funzionare con script remoti caricati tramite loadScript. Infatti, questo è stato il motivo principale del passaggio: non abbiamo più bisogno di elencare in anticipo ogni singolo URL di script esterno. Ciò è particolarmente utile per chi gestisce annunci pubblicitari, che spesso utilizzano una grande quantità di script remoti.
Stavo riscontrando alcuni errori, ma potrebbe non essere per questo motivo. Vediamo se riesco a trovare un esempio.
Mi stavo principalmente preparando per un aggiornamento stabile che so comporta loadScript e script remoti.
Puoi assecondarmi e spiegarmi come gli script remoti che vengono richiamati casualmente nel codice con loadScript finiscono per essere “autorizzati” dalla CSP in modalità dinamica? Sta succedendo qualcosa di magico?
L’espressione sorgente 'strict-dynamic' specifica che la fiducia data esplicitamente a uno script presente nel markup, accompagnandolo con un nonce o un hash, verrà propagata a tutti gli script caricati da quello script radice.
Quindi, finché lo script originale è attendibile (tramite un nonce), il browser consente di caricare qualsiasi altro script senza restrizioni. E poi, poiché tali script sono attendibili, possono caricarne altri!
C’è un’unica avvertenza, ovvero che gli script non possono essere “inseriti dal parser”. Questo impedisce che strict-dynamic venga sfruttato per attacchi XSS.
Quindi, ad esempio, questo verrebbe “inserito dal parser” e verrebbe bloccato:
Ma la costruzione dell’elemento script programmaticamente non comporta l’analisi HTML, è molto meno probabile che sia un vettore XSS, e quindi è consentito:
No, il nonce è incluso solo nel tag dello script originale renderizzato da Rails (ad esempio, script core, plugin o tema).
Ciò significa che il codice core/plugin/tema è considerato attendibile e può inserire qualsiasi altro script. Non è necessario alcun nonce: il browser sa quale script ha eseguito l’inserimento e sa magicamente che può essere considerato attendibile.
