No unsafe-inline

Descrizione

Content Security Policy (CSP) è uno standard di sicurezza informatica introdotto per prevenire cross-site scripting (XSS), clickjacking e altri attacchi di iniezione di codice risultanti dall’esecuzione di contenuti dannosi nel contesto di una pagina Web attendibile.
Il cross-site scripting (XSS) è un tipo di vulnerabilità di sicurezza che può essere trovata in alcune applicazioni web.
Gli attacchi XSS consentono agli aggressori di iniettare script lato client nelle pagine Web visualizzate da altri utenti.
Una vulnerabilità di tipo cross-site scripting può essere utilizzata dagli aggressori per aggirare i controlli di accesso come il criterio della stessa origine (same-origin).
Osservando il National Vulnerability Database gestito dal NIST statunitense, vengono segnalate più di 900 (Marzo 2024) vulnerabilità comeXSS per temi e plugin di WordPress.

Mantenere aggiornato il tuo sito con le ultime versioni di plugin e temi è la prima linea di difesa per garantire la sicurezza del tuo sito.

La seconda cosa da fare è implementare una rigorosa politica di sicurezza dei contenuti (CSP).

Il problema principale

Il problema principale con le politiche di sicurezza dei contenuti implementate nel mondo reale è che sono troppo deboli per proteggere davvero il tuo sito e che molte di esse possono essere banalmente aggirate da un attaccante.

La soluzione proposta

I ricercatori di Google consigliano, invece della whitelist dell’intero host, di attivare i singoli script tramite un approccio CSP nonces.
Inoltre, al fine di facilitare l’adozione di CSP basate sui nonce, hanno proposto la parola chiave ‘strict-dynamic’.

I problemi con la CSP in WordPress

1. Creazione manuale di una policy

   Di solito, un progetto WordPress è un mix di codice scritto da diversi autori che hanno contribuito al Core e/o hanno scritto plugin e temi.
   Se è possibile inserire nella whitelist ogni script esterno caricato da un <script src="">, la verità è che in un progetto WordPress puoi avere dozzine di quegli script inclusi nei tuoi plugin e calcolare un hash crittografico per ciascuno di essi da includere nell’intestazione CSP può essere un lavoro frustrante. Tuttavia, ci sono molte estensioni del browser e plugin di WordPress che possono aiutarti in questo lavoro.

2. Script inline

   Il core di WordPress e i plugin utilizzano script inline. Per questi script, puoi calcolare gli hash da inserire manualmente nella tua policy, solo se questi script non cambiano ad ogni caricamento della pagina. Sfortunatamente, questo non è molto comune in quanto è frequente includere valori di variabili calcolati lato server negli script inline. E questo significa che i tuoi script inline cambiano troppo frequentemente per aggiungere manualmente i loro hash alla tua politica.
   Questo accade comunemente quando gli script sono localizzati.

3. WordPress non ha API per implementare i nonce per la CSP

   Anche se è facile generare un nonce per ogni visualizzazione di pagina, questo nonce deve essere inserito in ogni tag di script utilizzato per incorporare gli script inline nella tua pagina come

   <script nonce="rAnd0m">
       doWhatever();
   </script>
   

   e nella tua direttiva script-src:

   script-src 'nonce-rAnd0m';
   

   E, naturalmente, un nonce deve essere univoco per ogni risposta HTTP.

4. Hash non sicuri / stili inline

   Sometimes, HTML elements as images or buttons use HTML Event Attributes (onclick, onsubmit…) to let events to trigger actions in a browser.
   You cannot use hashes or nonces for script included in event attributes and, adopting a strict CSP, requires refactoring those patterns into safer alternatives or to use ‘unsafe-hashes’.
   You got a similar problem when inline styles are used in HTML tags:

   <h1 style="color:blue;text-align:center;">This is a heading</h1>
   <p style="color:red;">This is a paragraph.</p>
   

   I browser CSP di livello 2 potrebbero andare bene semplicemente inserendo l’hash nella tua direttiva style-src. Tuttavia, nell’autorizzare gli hash nell’attributo style dei CSS inline nei browser che supportano CSP Livello 3, potresti ricevere un errore come questo

       Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='". Either the 'unsafe-inline' keyword, a hash ('sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='), or a nonce ('nonce-...') is required to enable inline execution.
   

   Per consentire gli stili inline devi usare ‘unsafe-hashes’ nella tua direttiva style-src (che è, in effetti, una keyword insicura).

L’approccio di questo plugin

Questo plugin affronta questi problemi in questo modo.

1. Durante una fase di acquisizione, rileva gli script, gli stili e altri contenuti incorporati presenti nelle pagine del tuo sito e li archivia nel database.
2. Quindi devi aggiungere in whitelist questi contenuti dal pannello di amministrazione del plugin.
3. Il plugin utilizza l’apprendimento automatico per raggruppare gli script inline cercando di aggregare gli script generati dallo stesso codice lato server (PHP). Pertanto, puoi autorizzare un esempio di script per autorizzare tutti gli script che il classificatore prevede di etichettare in dei cluster aggiunti in whitelist.
4. Puoi scegliere di utilizzare gli hash per autorizzare script esterni (e il plugin ti consentirà di includere la Subresource Integrity nei tuoi <script> e nei <link>)
5. Puoi usare hash o nonce per autorizzare gli script in linea.
6. Puoi chiedere al plugin di riscrivere la tua pagina per non utilizzare gli attributi degli eventi (convertiti in uno script in linea) e gli stili in linea (convertiti in un CSS interno).
7. È possibile impostare uno o più endpoint di segnalazione delle violazioni.

Il plugin supporta installazioni multisito e ha molte (troppe) opzioni documentate nella guida in linea.

Creare una politica sulla sicurezza dei contenuti

Dopo l’attivazione del plug-in, vai al menu Impostazioni e cerca il sottomenu Impostazioni CSP.
I passaggi che dovresti fare sono i seguenti.

1. Dalla scheda Strumenti, attiva la cattura dei tag e utilizza il tuo sito visitando tutte le pagine o facendole visitare dai tuoi utenti per un periodo molto lungo in base all’utilizzo del tuo sito (ore o giorni).
2. Dalla scheda Strumenti eseguire il clustering dei dati nel database (può utilizzare molte risorse del server).
3. Vai alla scheda Regole di base e includi nelle direttive CSP i valori desiderati (aiutati con la tabella a fondo pagina).
4. Vai alla scheda degli script esterni, alla scheda degli script in linea e alla scheda degli script invocati dai gestori di eventi e autorizza l’esecuzione di tutti gli script legittimi presenti nelle pagine del tuo sito.
5. Lasciando attiva la cattura del tag, attiva il test della policy (in questa fase il plugin genererà alcune violazioni della policy temporanea utilizzata per registrare valori aggiuntivi da inserire nelle direttive della tua “content security policy”).
6. Dopo aver visitato nuovamente le pagine del tuo sito, disabilita l’acquisizione dei tag e ripeti i precedenti passaggi 2, 3 e 4.
7. Abilita la protezione del sito.

NB Quando aggiorni plugin o temi, se qualcosa non funziona correttamente nelle pagine del tuo sito, disattiva temporaneamente la protezione e ripeti i passaggi da 1 a 7.

Codice e librerie

Questa versione del plugin utilizza
* ivopetkov/HTML5DOMDocument per processare l’HTML;
* RubixML per il machine learning dalla versione 1.1.0 – PHP-ML è utilizzata nelle versioni 1.0.x;
* opctim/php-nilsimsa per calcolare e confrontare i digest Nilsimsa.

Le funzioni per i log sono state prese da
* perfectyorg/perfecty-push-wp, una cosa che dovresti realmente provare se vuoi implementare le notifiche Push sul tuo sito.

La lista completa delle dipendenze utilizzate in questo plugin può essere vista nel grafico delle dipendenze su GitHub.

Contributi, problemi, bug

Il codice del plugin è ospitato su un repository pubblico su GitHub.
Vieni a trovarmi lì per aiutarmi e dare i tuoi suggerimenti.