Header HTTP

Articolo di rivista

Questo articolo è basato su un articolo del Joomla! Community Magazine scritto da Brendan Hedges nell'edizione di maggio 2022. Sebbene sia stato scritto per Joomla 4, il contenuto si applica ugualmente a Joomla 5.

Per chi trova questo argomento difficile da comprendere, c'è un articolo illuminante di Scott Helme su Content Security Policy - An Introduction.

Il nuovo plugin HTTP Headers di Joomla per J4

Proseguendo dall'articolo del mese scorso sulla sicurezza, le password e il plugin WebAuthn di Joomla, questo mese esamineremo un'altra funzionalità di sicurezza di Joomla lanciata con J4. Si tratta del plugin HTTP Headers, ora incluso tra le funzioni core di Joomla.

Internet è in continua evoluzione e Joomla non è mai molto indietro. Questo è il motivo per cui lo scelgo come piattaforma di sviluppo web preferita. Che il tuo sito web sia un piccolo sito familiare o una piattaforma di e-commerce a tutti gli effetti con milioni in vendite, il framework Joomla ha qualcosa per tutti, ed è sempre alla ricerca di implementare nuove tecnologie. Alcune sono persino rivoluzionarie.

L'introduzione del plugin HTTP Headers nel core di Joomla 4 è un enorme passo avanti per aiutare a proteggere il tuo sito web da attacchi e attività malevole.

Questo plugin di sicurezza di sistema aiuta i proprietari dei siti a configurare facilmente le intestazioni di sicurezza HTTP dal familiare backend di Joomla, invece di dover frugare nel file htaccess o in altri file di configurazione. O, peggio ancora, nel Cpanel del tuo hosting web.

Guarda quanto è complicato impostare questo nel Cpanel e dimmi che non farai un errore! E questo presumendo che, una volta installato il framework in Apache e creati i direttori, tu conosca il formato corretto per aggiungere le intestazioni HTTP che desideri integrare.

Quante volte hai provato a implementare un comando htaccess solo per ricaricare il tuo sito web e poi affrontare un errore http500?

Il problema più grande è che se non ottieni il formato della tua intestazione HTTP perfetto, romperai il tuo sito.

Anche così, ciò che funziona per un sito web potrebbe non funzionare per un altro. Un buon esempio di questo è il mio file htaccess e il modo in cui ho impostato il browser per caricare una versione https non www del mio sito web:

##www to non www and http to https mixin
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://mywebsite.co.uk%{REQUEST_URI} [R=301,L,NE]
##End www to non www and http to https mixin

Questo ha funzionato benissimo per la mia precedente azienda di hosting. Ma quando sono passato a un host diverso, ha smesso di funzionare. Vai a capire!

Il codice htaccess che ora devo usare per ottenere lo stesso risultato è così:

##www to non www and http to https mixin
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
##End www to non www and http to https mixin

Confuso, vero? E se fai un singolo errore nella formattazione, BAM! Hai rotto il tuo sito web! Beh, almeno finché non correggi il tuo codice.

Ecco perché mantenere le cose semplici, come parte del core di Joomla, significa meno frustrazione, meno tempo sprecato a cercare su Google i tuoi errori, e più tempo per festeggiare mentre ti siedi comodamente sulla sedia ad ammirare il tuo nuovo sito web.

Quindi, vediamo cosa sono realmente gli HTTP headers, come trovare il plugin e cosa puoi fare con essi. Vale comunque la pena menzionare che questa funzione di Joomla è una funzione avanzata, più adatta a siti web che gestiscono dati sensibili, piuttosto che al nuovo sito che hai creato con affetto sui tuoi adorabili gattini. Detto ciò, anche i siti web semplici dovrebbero essere il più sicuri possibile per impedire l'esecuzione di codice dannoso dopo che il tuo sito è stato violato.

Cosa sono gli HTTP Headers?

Gli HTTP headers non devono essere confusi con la sezione <head> del tuo documento HTML. Sono completamente diversi. Gli HTTP headers sono il preambolo tra il tuo server web e il browser. Un insieme di istruzioni che dicono al browser cosa mostrare, o più importante, cosa non mostrare al visitatore.

Puoi vedere gli HTTP Headers e come si riferiscono ai singoli oggetti HTML negli strumenti di sviluppo del tuo browser. In Google Chrome, apri gli Strumenti per sviluppatori, poi la scheda Rete. Ora aggiorna la pagina web e clicca su un elemento HTML nel pannello sinistro. Verrà mostrato l'HTTP Header per quell'elemento nel pannello destro.

Puoi vedere nell'immagine sottostante che l'immagine evidenziata restituisce uno stato HTTP 200, quindi il browser l'ha trovata. Ci sono anche altre informazioni collegate a quell'elemento, come la dimensione del file e le date di modifica.

Se uno dei tuoi elementi HTML non viene mostrato, potresti trovare un indizio sul motivo anche negli HTTP headers. In questo esempio, la seconda immagine non è stata mostrata e puoi vedere dalle informazioni nel pannello di destra che non ci sono informazioni nell'HTTP Header.

Tranne il criptico messaggio:

Referrer Policy: 'strict-origin-when-cross-origin'

'Strict-origin-when-cross-origin' significa semplicemente che quando un elemento HTML (in questo caso un'immagine) viene servito da una fonte diversa (non il tuo server), allora deve essere seguita la policy HTTP header impostata in quel momento. In questo esempio gli HTTP Headers, come impostati nel plugin Joomla, rifiuteranno tutte le immagini che non provengono né da questo sito web, né da un altro sito web specificamente 'incluso' nei parametri dell'HTTP Header impostati nel plugin HTTP Headers di Joomla.

Quindi, quando l'immagine viene richiamata dal documento HTML, il browser la rifiuta e non viene caricata.

Questo differisce dal caso in cui l'elemento non viene trovato e viene restituito un messaggio di errore HTTP 404 non trovato. In questa situazione, l'immagine viene comunque cercata sul server che la ospita, ma il browser non l'ha trovata.

Cosa fa il plugin HTTP Headers di Joomla

Oltre a dire al browser cosa mostrare e restituire informazioni generali sul documento HTML, gli HTTP Headers aiutano a mitigare attacchi e vulnerabilità di sicurezza che potresti avere sul tuo sito web Joomla. È qui che il plugin HTTP Headers di Joomla entra in gioco. Raggiunge questo obiettivo mostrando esplicitamente i contenuti HTML in base alle impostazioni del plugin HTTP Headers di Joomla stesso.

Aggiungendo ulteriori HTTP headers basati sulla sicurezza al tuo sito web Joomla con il plugin HTTP Headers, fornirai un ulteriore livello di sicurezza per il tuo sito web Joomla.

Questo è importante, perché per impostazione predefinita una pagina web HTML mostrerà tutti i suoi contenuti al visitatore, buoni o cattivi. A meno che non le venga esplicitamente detto di non farlo negli HTTP headers della pagina web. Il plugin fa questo consentendoti di configurare le opzioni di sicurezza avanzate disponibili nella Content-Security-Policy per il tuo sito web. Il plugin può essere configurato diversamente per ogni sito web in base alle tue esigenze, quindi è una vera e propria arma flessibile nel tuo arsenale contro gli hacker.

Perché ho bisogno di questo plugin?

In un mondo ideale, non ne avresti bisogno. Tuttavia, nel mondo in cui viviamo, ci sono fin troppe persone senza scrupoli che cercano di trovare modi per guadagnare denaro a scapito degli innocenti e dei disattenti. Nel nostro mondo, chiamiamo queste persone hacker. Gli hacker fanno di tutto per sfruttare le vulnerabilità del software a scopo di lucro, spesso a discapito del proprietario del sito web.

Utilizzando il plugin HTTP Headers di Joomla per controllare quali contenuti vengono serviti ai tuoi visitatori, riduci le possibilità che gli hacker possano servire contenuti dannosi ai tuoi visitatori tramite plugin obsoleti e vulnerabili. Questo aiuta a bloccare le iniezioni di script dannosi sul tuo sito web.

Quindi, riflettiamo un momento su questa situazione ipotetica.

Hai un bel sito web Joomla 3. È stato realizzato 5 anni fa, e funziona ancora perfettamente. Tutti i tuoi componenti, plugin e moduli sono aggiornati. Perfetto, giusto?

Be', non proprio, perché quando hai creato il tuo sito web 5 anni fa, hai installato il trendy plugin Foo Bar per stampare "FOO BAR" sulla tua homepage. All'inizio sembrava interessante, ma dopo un po' hai cambiato idea e hai eliminato lo shortcode del plugin {foo}FOO - BAR{/bar} dal tuo articolo di homepage.

Ma, ecco il problema: non hai annullato la pubblicazione né disinstallato il plugin stesso, e il suo utilizzo è svanito dalla memoria. Questo è qualcosa di cui siamo TUTTI colpevoli, ne sono sicuro.

Facendo un salto a oggi, 5 anni dopo, quel plugin è ancora lì, pubblicato e attivo sul tuo sito web, ma non è stato aggiornato da 5 anni perché te ne sei dimenticato da tempo, oppure l'autore ha smesso di supportarlo. Ora, qualche losco individuo si è accorto che questo plugin presenta una vulnerabilità di sicurezza che può essere sfruttata per avviare un attacco di Cross Site Scripting (XSS) sul tuo sito web, rendendo le tue ignare vittime i tuoi visitatori.

Il cross-site scripting, noto anche come XSS, è una vulnerabilità di sicurezza nel tuo sito web che consente a un attaccante di compromettere le interazioni che i tuoi utenti hanno con il tuo sito web ora vulnerabile.

L'attaccante/hacker utilizza l'XSS per sfruttare il tuo sito web vulnerabile e inviare uno script dannoso al tuo utente ignaro. Poiché lo script proviene dal tuo sito web, il browser del tuo utente non sa né sospetta che lo script non debba essere considerato attendibile ed esegue lo script quando la pagina web si carica e si apre.

Gli script dannosi eseguiti in questo modo possono causare molti problemi per il tuo utente, dal furto di password di accesso e dati del nome utente conservati nei cookie, all'invio del tuo utente a falsi siti web di phishing. Gli script possono persino modificare l'aspetto della pagina web che il tuo sito web sta servendo e mostrare pubblicità diverse.

Utilizzare il plugin HTTP Headers di Joomla aiuta a bloccare il cross-site scripting assicurando che vengano effettivamente serviti solo gli script e i contenuti che desideri fornire al tuo visitatore. Tutto il resto viene bloccato.

Quindi, nell'esempio sopra, avresti potuto configurare il plugin HTTP Headers per servire i file JavaScript (script) del tuo sito web solo da una cartella specificata, o magari da una CDN se ne usi una, per fermare l'attacco.

Potresti anche impedire al sito web di eseguire JavaScript inline incorporato nell'HTML. Ma, tieni presente che a seconda di come hai progettato l'HTML del tuo sito web, questo potrebbe causare problemi in futuro.

Questo aiuterebbe quindi a impedire l'esecuzione di codice JavaScript dannoso sul tuo sito web. Anche se la colpa fosse del tuo vulnerabile plugin Foo Bar per aver permesso a un hacker di iniettare codice dannoso nel tuo sito web.

Nota:

I punti deboli comuni nei siti web soggetti ad attacchi XSS sono i moduli di input dell'utente (pagine di accesso, moduli di iscrizione alla newsletter, moduli di contatto, ecc.) privi di convalida e crittografia.

Dove si trova il plugin HTTP Headers?

Puoi trovare il plugin HTTP Headers di Joomla insieme a tutti gli altri plugin di Joomla e vi si accede esattamente allo stesso modo a cui sei abituato.

Utilizzo del plugin HTTP Headers

Utilizzare il plugin HTTP di Joomla è relativamente semplice, anche se prima di modificare le impostazioni predefinite potrebbe essere una buona idea informarsi su alcuni dei termini speciali relativi al suo utilizzo. Anche se, detto questo, alcuni di essi dovrebbero già esserti familiari.

Ad esempio:

Quando si ha a che fare con le immagini, vedrai il termine 'img-src', dove 'img' si riferisce alle immagini e 'src' alla sorgente valida dell'immagine. Si tratta di termini che già conosciamo dall'HTML di base.

Alla fine di questo articolo, troverai un elenco di siti web utili con ulteriori informazioni per aiutarti a utilizzare questo plugin di Joomla.

Impostazioni del plugin HTTP Headers - Scheda 1

Quando apri il plugin, la prima scheda aperta è quella delle impostazioni di base del plugin. Qui puoi apportare modifiche a X-Frame Options, Referrer-Policy, Cross-Origin-Opener-Policy e anche Force HTTP Headers. Ci sono anche alcuni link per maggiori informazioni che ti aiuteranno a capire più in dettaglio cosa fanno questi elementi.

Esaminiamoli uno per uno.

X-Frame Options

La prima impostazione riguarda le X-Frame Options. È abilitata per impostazione predefinita.

Questa opzione ti consente di decidere se i contenuti del tuo sito web possono essere mostrati su un altro sito web in un <frame>, <iframe>, <embed> o <object>. Se disabiliti questa opzione, qualsiasi altro sito web potrà mostrare il tuo sito in un iframe.

Una volta abilitata, un tag 'x-frame-options: SAMEORIGIN' viene aggiunto alle intestazioni del tuo sito web. Questo tag ti consente comunque di mostrare i tuoi contenuti in un <frame>, <iframe>, <embed> o <object>, sul tuo stesso sito web. Ma nessun altro potrà mostrare i tuoi contenuti in un <iframe> sul proprio sito web.

L'intestazione X-Frame Option aiuta a proteggere il tuo sito web e i tuoi utenti dagli attacchi di 'Click Jacking'. Si tratta di un caso in cui un attaccante inserisce un <iframe> sul proprio sito web e imposta come sorgente dell'<iframe> il tuo sito web. Poi l'attaccante utilizza più livelli trasparenti del proprio sito web sopra di esso.

Questo induce l'utente a cliccare su un pulsante o un link nel livello superiore trasparente, perché l'utente crede di cliccare su un link nell'iframe sottostante.

Quindi, l'attaccante sta 'dirottando' i clic destinati alla pagina originale incorniciata e inviandoli a una pagina web diversa.

Più seriamente, pratiche simili possono essere utilizzate per raccogliere le sequenze di tasti relative alle credenziali di accesso di password e nomi utente da account e-mail, account di social media e, naturalmente, dal tuo conto bancario.

La maggior parte dei browser moderni supporta le X-Frame Options, il che è un bene. Pertanto, il mio consiglio è di abilitare questa impostazione nel plugin HTTP headers per aiutare a proteggere i tuoi utenti dal diventare vittime del 'Click Jacking'.

La maggior parte dei browser moderni supporta le X-Frame Options.

Referrer-Policy

Il prossimo elemento della lista nella prima scheda è la Referrer-Policy. Questa, se abilitata, ti permette di scegliere quanta parte dei dati potenziali del tuo sito web venga trasferita a un altro sito web se un link, o un altro oggetto HTML, viene cliccato sul tuo sito.

Comunemente, vediamo questa impostazione come attributo HTML sui tag <a>, dove potresti formattare un link come <a href=”https://someplace.com” rel=”noreferrer”>Clicca qui</a>. Il tag noreferrer mantiene segreti i dettagli della pagina web mittente dalla pagina web ricevente. Lo fa rimuovendo le informazioni sul referente dall'HTTP header della pagina web.

Essere consapevoli dei dati che il tuo sito web potrebbe 'far trapelare' verso un altro sito web a cui ti colleghi è una parte importante della protezione del tuo sito e dei suoi utenti.

Questo è particolarmente vero se consenti agli utenti di registrarsi, se il sito contiene dati sensibili, o se il tuo sito web gestisce transazioni monetarie. Il plugin HTTP Headers di Joomla aiuta a controllare questo aspetto a livello globale, piuttosto che a livello di singolo link.

Per impostazione predefinita, la Referrer Policy del tuo sito web è impostata su 'strict-origin-when-cross-origin'. Che non blocca nessuno dei dati del referente dalla pagina web di origine a meno che non venga inviata a una pagina http meno sicura. Ma, poiché la maggior parte delle pagine web oggi usa https, questo è ora un problema più grande di quanto non fosse una volta.

Ci sono, ovviamente, molti usi innocenti di questi dati 'trapelati' se non stabilisci una Referrer Policy per il tuo sito web. Questi potrebbero includere dati raccolti dal sito web collegato per analisi, logging, o caching ottimizzato.

Sfortunatamente, non tutti i siti web di riferimento là fuori usano i tuoi dati 'trapelati' per operazioni così innocenti. Prendi in considerazione la seguente situazione come esempio.

La maggior parte dei siti web che consentono la registrazione degli utenti avrà un link per il reset della password accanto al modulo di accesso in una pagina di login/registrazione. È anche probabile che la pagina contenga anche altri link a siti web esterni, link ai social media, o magari ci sono alcuni 'Link utili' nel footer.

Tutti questi portano lontano dal tuo ambiente sicuro. Ora, se non è presente alcuna Referrer Policy, è possibile che l'HTTP header del referente inviato a uno di quei siti web esterni quando si clicca su un link da quella pagina di login, contenga il link di reset della password. Oltre ad altre informazioni che hai condiviso con quel sito web esterno.

Questo potrebbe rappresentare un rischio per la sicurezza dell'utente compromettendo i suoi dati.

A causa del potenziale rischio di sicurezza su questo tipo di pagina sensibile ai dati, è anche buona pratica rimuovere tutti i contenuti di terze parti dalla pagina. Questo includerebbe tutti i link e i contenuti forniti in <iframe> come i widget dei social media e i video di YouTube. Poiché i dati inseriti in questa pagina potrebbero essere inviati tramite l'HTTP header del referente a quei siti se clicchi su quel simpatico video di gattini che è appena apparso.

Il plugin HTTP Headers di Joomla affronta questo problema permettendoti di scegliere tra una di 8 Referrer Policy per stabilire una Referrer Policy per il tuo sito web. Ognuna con i propri limiti su quando e quanti dati condividere.

Diamo un'occhiata a queste opzioni. C'è un'ottima descrizione sulla pagina Headers di Mozilla, che le descrive come:

• no-referrer
  L'HTTP header del referente sarà omesso: le richieste inviate non includono alcuna informazione sul referente.
• no-referrer-when-downgrade
  Invia l'origine, il percorso e la stringa di query nell'HTTP header del referente quando il livello di sicurezza del protocollo rimane invariato o migliora (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Non invia l'HTTP header del referente per le richieste verso destinazioni meno sicure (HTTPS→HTTP, HTTPS→file).
• origin
  Invia solo l'origine nell'HTTP header del referente. Ad esempio, un documento su https://example.com/page.html invierà come referente https://example.com/.
• origin-when-cross-origin
  Quando si esegue una richiesta dello stesso livello di protocollo (HTTP→HTTP, HTTPS→HTTPS), invia l'origine, il percorso e la stringa di query. Invia solo l'origine per le richieste cross-origin e per le richieste verso destinazioni meno sicure (HTTPS→HTTP).
• same-origin
  Invia l'origine, il percorso e la stringa di query per le richieste dello stesso origine. Non invia l'HTTP header del referente per le richieste cross-origin.
• strict-origin
  Invia solo l'origine quando il livello di sicurezza del protocollo rimane invariato (HTTPS→HTTPS). Non invia l'HTTP header del referente verso destinazioni meno sicure (HTTPS→HTTP).
• strict-origin-when-cross-origin (predefinito)
  Invia l'origine, il percorso e la stringa di query quando si esegue una richiesta dello stesso origine. Per le richieste cross-origin invia solo l'origine quando il livello di sicurezza del protocollo rimane invariato (HTTPS→HTTPS). Non invia l'HTTP header del referente verso destinazioni meno sicure (HTTPS→HTTP). Nota: questa è la politica predefinita se non si specifica una politica, o se il valore fornito non è valido. In precedenza, il valore predefinito era no-referrer-when-downgrade.
• unsafe-url
  Invia l'origine, il percorso e la stringa di query per qualsiasi richiesta, indipendentemente dalla sicurezza. Attenzione: questa politica potrebbe far trapelare informazioni potenzialmente private dagli URL di risorse HTTPS verso origini non sicure. Valutare attentamente l'impatto di questa impostazione.

Cross-Origin-Opener-Policy

La terza opzione da impostare nella prima scheda è la Cross-Origin-Opener-Policy, una funzione di sicurezza basata sul browser che consente di disconnettere tra loro diversi 'Gruppi di contesto del browser'.

Un buon esempio è l'uso dei popup. In questo caso, il gruppo di contesto del browser originale (tutto il testo, le immagini, i link, ecc.) viene disconnesso da un nuovo gruppo di contesto del browser che viene creato e poi mostrato nel popup.

Questa opzione HTTP Header è piuttosto approfondita e complicata, sebbene ci siano solo 3 opzioni. Quindi ti consigliamo di consultare i link qui sotto per capire meglio perché questa opzione dovrebbe essere impostata sul tuo sito web. Oltre a imparare alcune delle funzionalità avanzate che diventano disponibili quando questa opzione è attiva.

La Cross Origin Opener Policy aiuta a chiudere una falla storica nel modo in cui i browser condividono i dati tra diversi gruppi di contesto, in particolare quando i pop-up sono in uso sul sito web.

Impostare la tua COOP ti aiuterà a mitigare le minacce alla sicurezza dei dati, quella comune è denominata ‘Spectre’. Spectre rende i dati caricati nello stesso gruppo di contesto del browser del tuo codice potenzialmente leggibili da un hacker. Spectre consente di misurare il tempo che determinate operazioni impiegano. Questo permette agli hacker di indovinare cosa c’è nella cache della CPU. Se ci riescono, sapranno cosa c’è nella memoria di processo. A quel punto hanno accesso ai tuoi dati, che potrebbero essere sensibili.

COOP funziona isolando i dati del tuo documento HTML originale dai dati HTML che verrebbero mostrati in un pop-up dal documento originale. Questo aiuta a prevenire quelli che vengono chiamati attacchi cross-origin, o XS-Leaks.

Questo processo è simile al familiare rel=”noopener” che utilizziamo nei link normali. Ma, a differenza di rel=”noopener” che è attivo solo sui link in uscita, i documenti che hanno la cross-origin-opener-policy impostata negli HTTP headers dal plugin Joomla, limitano i dati in entrambe le direzioni. Pertanto, il documento HTML con una policy COOP attiva non avrà riferimento ad esso nell’HTTP Header, e la proprietà window.opener dell’HTTP Header della nuova finestra sarà impostata su null.

Quando imposti questa opzione nel plugin HTTP Header di Joomla, hai a disposizione 3 opzioni.

• unsafe-none
  Questo è il valore predefinito. Consente al tuo documento di essere aggiunto al gruppo di contesto del browser del suo apritore, a meno che l’apritore stesso non abbia una cross-origin-opener-policy impostata su same-origin o same-origin-allow-pop-ups.
• same-origin-allow-popups
  Questa opzione mantiene i riferimenti a finestre o schede appena aperte che non impostano una cross-origin-opener-policy, o che rinunciano all’isolamento impostando essi stessi una cross-origin-opener-policy su unsafe-none.
• same-origin
  Isola il gruppo di contesto del browser solo ai documenti della stessa origine. I documenti cross-origin non vengono caricati nello stesso gruppo di contesto del browser.

Force HTTP Headers

L’ultima opzione su cui concentrarsi nella prima scheda è Force HTTP Headers, da non confondere con ‘Force HTTPS’ nelle impostazioni generali di Joomla.

Questa sezione del plugin HTTP Headers di Joomla consente di aggiungere, se lo si desidera, una selezione di 'altri' header non specificatamente dettagliati nelle schede del plugin, nonché di forzare l'inclusione di alcuni di quelli già inclusi.

Dal menu a tendina, attualmente sono disponibili 10 opzioni. Tuttavia, è bene notare che alcune di queste potrebbero essere rimosse nel tempo in quanto le policy degli header a cui si riferiscono sono destinate a cambiare, o essere ripensate.

Gli attuali HTTP headers che è possibile impostare direttamente qui sono header che riguardano quanto segue:

È possibile ottenere maggiori informazioni su ciascuna funzionalità sul sito web di Mozilla Developers.

Content-Security-Policy (lista)

L'header di risposta Content-Security-Policy consente ai siti web di controllare le risorse che l'utente può caricare per ciascuna pagina web. Le policy specificano principalmente le origini del server e gli endpoint degli script. Questo aiuta a proteggere contro gli attacchi di cross-site scripting. Mozilla: Content-Security-Policy

Content-Security-Policy-Report-Only

L'header di risposta HTTP Content-Security-Policy-Report-Only consente agli sviluppatori web di sperimentare con le policy monitorando (ma non applicando) i loro effetti. Mozilla: Content-Security-Policy-Report-Only

Cross-Origin-Opener-Policy (COOP)

L'header di risposta HTTP Cross-Origin-Opener-Policy (COOP) consente di garantire che un documento di primo livello non condivida un gruppo di contesto del browser con documenti cross-origin. Mozilla: Cross-Origin-Opener-Policy

COOP isolerà il processo del tuo documento e i potenziali attaccanti non potranno accedere al tuo oggetto globale se lo aprissero in un pop-up, prevenendo un insieme di attacchi cross-origin denominati XS-Leaks.

Expect-CT (in via di dismissione)

L'header Expect-CT consente ai siti di attivare la segnalazione e/o l'applicazione dei requisiti di Certificate Transparency, per evitare che l'uso di certificati emessi erroneamente per quel sito passi inosservato. Mozilla: Expect-CT (in via di dismissione)

Feature-Policy (ora deprecato)

L'header HTTP Feature-Policy fornisce un meccanismo per consentire e negare l'uso delle funzionalità del browser nel proprio frame, e nei contenuti all'interno di qualsiasi elemento <iframe> nel documento. Mozilla: Feature-Policy

Permissions-Policy

Questo è il sostituto del Feature-Policy sopra indicato. Mozilla: Permissions-Policy (sostituisce Feature Policy sopra)

Referrer-Policy (in lista)

L'header HTTP Referrer-Policy controlla quante informazioni sul referente (inviate con l'HTTP header del referente) debbano essere incluse nelle richieste. Mozilla: Referrer-Policy

Report-To

Parte del Content-Security-Policy. Il campo dell'header di risposta HTTP Content-Security-Policy Report-To istruisce lo user agent a memorizzare gli endpoint di segnalazione per un'origine. Mozilla: Report-To

La direttiva report-to è destinata a sostituire la direttiva deprecata report-uri, report-to non è ancora supportata dalla maggior parte dei browser.

Strict-Transport-Security

L'header di risposta HTTP Strict-Transport-Security (spesso abbreviato in HSTS) informa i browser che il sito debba essere accessibile solo tramite HTTPS, e che qualsiasi tentativo futuro di accedervi tramite HTTP debba essere automaticamente convertito in HTTPS. Mozilla: Strict-Transport-Security

Questo è più sicuro rispetto alla semplice configurazione di un reindirizzamento (301) da HTTP a HTTPS sul tuo server, dove la connessione HTTP iniziale è ancora vulnerabile a un attacco man-in-the-middle.

X-Frame-Options (in lista)

L'header di risposta HTTP X-Frame-Options indica se a un browser debba essere consentito o meno il rendering di una pagina in un <frame>, <iframe>, <embed> o <object>. I siti possono usare questo per evitare attacchi di click-jacking, assicurandosi che i loro contenuti non siano incorporati in altri siti. Mozilla: X-Frame-Options

La sicurezza aggiuntiva è fornita solo se l'utente che accede al documento sta usando un browser che supporta X-Frame-Options.

L'header X-Frame-Options ha elementi derivati chiamati frame-ancestors che sostituiscono l'header Frame-Options. Se una risorsa presenta entrambe le policy, verrà applicata la policy frame-ancestors e quella X-Frame-Options sarà ignorata.

Utilizzando il campo HTTP Header Value, puoi impostare i valori che desideri seguire e assegnarli al tuo sito web, al sito di amministrazione, o a entrambi.

Impostazioni del plugin Header HTTP - Scheda 2

Strict-Transport-Security (HSTS)

La scheda Strict Transport Security Policy è disabilitata di default.

Adoro fare ricerche. Perché a volte ci si imbatte in un vero momento OMG! Questo è uno di quei momenti.

Wikipedia afferma:

Netscape Communications creò HTTPS nel 1994 per il suo browser web Netscape Navigator. Originariamente, HTTPS era usato con il protocollo SSL. Man mano che SSL si evolveva in Transport Layer Security (TLS), HTTPS fu formalmente specificato dall'RFC 2818 nel maggio 2000. Google annunciò nel febbraio 2018 che il suo browser Chrome avrebbe contrassegnato i siti HTTP come "Non sicuro", dopo luglio 2018. Questa mossa serviva a incoraggiare i proprietari dei siti web a implementare HTTPS, in uno sforzo per rendere il World Wide Web più sicuro.” ……

Chi avrebbe pensato che Netscape avesse inventato i protocolli HTTPS così tanto tempo fa? Ciò che è ancora più sorprendente è quanto tempo ci sia voluto per implementarlo in Internet come lo conosciamo e amiamo oggi.

Per anni ormai, ci hanno blanditi, intimiditi e infine minacciati, affinché implementassimo HTTPS su tutti i nostri siti web. La maggior parte di noi ha ceduto e il World Wide Web è ora finalmente sicuro. O forse no?

Ci sono, tuttavia, alcuni irriducibili, testardi o siti web dimenticati che usano ancora solo http per fornire i loro contenuti, seppure con un avviso "Questo sito web non è sicuro" di Google/Firefox ecc.

Una rapida ricerca su Google ha prodotto diverse liste obsolete di quei siti web ‘colpevoli di usare solo HTTP’. Sebbene dalla pubblicazione di quelle liste, molti siti web siano passati a HTTPS. Tuttavia, c'erano alcune evidenti esclusioni da parte di organizzazioni che ci si sarebbe aspettati sapessero fare di meglio.

Ad esempio:

• NGINX (http://nginx.org/)
• GNU (http://www.gnu.org/)
• The University of Washington (http://www.washington.edu/)

Secondo w3techs.com circa il 20% di tutti i siti web funziona ancora solo con HTTP.

Allora, perché è un problema?

Questo è un problema perché qualsiasi dato inviato da e ricevuto dal browser di un utente rischia di essere intercettato. Lo conosciamo come attacco man-in-the-middle. Ora, questo potrebbe non sembrare una considerazione importante se il tuo sito web riguarda solo foto di gattini carini.

Ma anche i siti web più semplici possono diventare vittime di hacker e aggressori che implementeranno il click-jacking e altri attacchi cross-origin che danneggeranno i tuoi utenti.

Un sito web che non scambia dati utente, o informazioni di accesso, dovrebbe comunque usare HTTPS.

Ok, torniamo in argomento.

Come già sai, lo scopo di HTTPS è introdurre una connessione sicura tra il browser dell'utente e il tuo server. Una connessione in cui ogni scambio di dati avviene in un ambiente sicuro che non può essere intercettato e copiato da terzi. Un uomo nel mezzo.

Ma sapevi che, a meno che il tuo certificato SSL HTTPS non utilizzi TLS, la tua connessione 'sicura' non è così sicura come ti aspetteresti? Le connessioni HTTPS non TLS sono ancora vulnerabili agli attacchi man-in-the-middle.

Sebbene sia un vecchio articolo di blog, questo articolo spiega bene come funziona un attacco man-in-the-middle.

I browser hanno ampiamente adottato TLS.

E TLS 1.3 non è direttamente compatibile con le versioni precedenti a meno che non venga eseguito in modalità di compatibilità. Il che potrebbe rappresentare un problema per alcuni.

Utilizzare il plugin HTTP Headers di Joomla per gestire Strict-Transport-Security (HSTS) aiuta a mitigare gli attacchi man-in-the-middle imponendo l'uso di TLS nel browser web dei tuoi visitatori. TLS garantisce che tutta la comunicazione web avvenga lato client utilizzando un livello di trasporto sicuro.

Stai utilizzando un reindirizzamento 301 per servire la versione non sicura HTTP del tuo sito web verso la versione sicura HTTPS?

La maggior parte delle persone lo fa. I reindirizzamenti 301 sono istruzioni che la maggior parte dei proprietari di siti web imposta nel proprio file htaccess. Comunicano a Google che la versione del sito web da utilizzare è quella HTTPS (sicura). Il problema è che il 301 è solo un reindirizzamento di URL, quindi il tuo sito web esegue comunque un elemento della connessione iniziale tramite HTTP.

A differenza delle connessioni tra un utente e un server del sito web che utilizzano HSTS, dove il server interagisce automaticamente solo tramite HTTPS.

HSTS ha comunque un punto debole, poiché la prima connessione iniziale tra il browser dell'utente e il server del sito web avviene comunque tramite HTTP. Ma tutte le connessioni successive vengono automaticamente collegate tramite HTTPS fino al raggiungimento della data di scadenza dell'HTTP header, quando questo header viene reimpostato.

Questo è diverso da un reindirizzamento 301 standard, dove ogni caricamento di pagina include una richiesta http iniziale per avviare la connessione https.

C'è una soluzione a questo punto debole nelle impostazioni HSTS di HTTP Headers: attiva 'Preload'.

Questo aggiungerà il tag 'Preload' all'header di risposta.

Nelle impostazioni è presente anche una link preload list**. Si tratta di una lista codificata direttamente in molti browser moderni. La lista informa il browser che la connessione a example.com deve essere effettuata solo tramite HTTPS. Eliminando così la necessità di effettuare anche la connessione iniziale tramite HTTP.

Una volta configurato HSTS nel plugin HTTP header di Joomla, tutti i tag necessari vengono aggiunti all'HTTP Response header. Questo comunica al browser di qualsiasi utente che tenta di connettersi al tuo server che tutte le connessioni devono essere effettuate con HTTPS, che sia specificato o meno nel tuo HTML.

In sintesi, utilizzare il plugin HTTP headers di Joomla per integrare HSTS invece di affidarsi ai reindirizzamenti 301 per servire i tuoi contenuti tramite HTTPS è un importante miglioramento della sicurezza. Un miglioramento che aiuta a fermare gli attacchi man-in-the-middle e fornisce ai tuoi utenti un ambiente sicuro.

HSTS copre l'intero dominio, a differenza di un reindirizzamento 301 che copre solo un percorso URI specifico.

HSTS utilizza una cache del browser separata che solitamente è segregata, quindi non può essere cancellata facilmente o accidentalmente.

È possibile precaricare HSTS in un browser. Questo garantisce che un utente si connetta al tuo server solo tramite HTTPS, indipendentemente dal fatto che abbia già visitato il sito in precedenza.

Impostazioni del plugin HTTP Headers - TAB 3

Content Security Policy (scheda 3)

La scheda Content Security Policy è disabilitata per impostazione predefinita.

Quando abiliti la Content Security Policy di Joomla tramite il plugin HTTP Headers, stai dicendo esattamente al browser dei tuoi visitatori quali asset caricare dal server del tuo sito web. Che è un ottimo modo per assicurarti di fornire solo i contenuti che intendi effettivamente fornire.

Avere una Content Security Policy efficace è un modo efficace per fermare attacchi di Cross-Site Scripting (XSS) e Click Jacking originati dal tuo sito web.

Il Cross-Site Scripting, noto anche come attacco XSS, è un attacco al tuo sito web in cui uno script dannoso viene “iniettato” in un sito web altrimenti fidato e ignaro. Gli aggressori trovano un punto debole da sfruttare, che di solito è dove un utente può inserire dati.

Componenti obsoleti che consentono l'input dell'utente, moduli di commento non validati, ad esempio, potrebbero avere vulnerabilità sfruttabili in un attacco Cross Site Scripting. Motivo per cui è buona norma aggiornare sempre i componenti Joomla e ridurre al minimo queste opportunità.

Quindi, usando come esempio il modulo di commenti infetto:

Il tuo sito web utilizza un modulo di commenti alla fine di un articolo per raccogliere la discussione degli utenti, come fanno molti siti web. Il che è fantastico.

La tua estensione per i commenti da dodgy-joomla-extensions.com funziona alla grande e i tuoi utenti la adorano. Ma non l'hai aggiornata da 5 anni e gli sviluppatori l'hanno abbandonata da tempo.

Ora, 5 anni dopo, il Sig. Hacker si rende conto che, a causa di una vulnerabilità nel codice del componente commenti, può nascondere un pezzo di codice dannoso in un commento che altrimenti sembra innocuo.

Ciò che quel codice fa alla fine varia, ma ciò su cui puoi contare è che ogni volta che la tua innocente pagina articolo si carica, con i commenti, anche quel codice dannoso viene caricato ed eseguito. Fa parte dell'HTML dopotutto, e il browser non sa che non dovrebbe essere lì, o che non è attendibile.

Quindi, il codice dannoso viene eseguito. Forse controlla i dati dei tuoi cookie. Forse ruba dati sensibili conservati dal browser. Oppure, forse carica pubblicità da casinò online, o siti web per adulti. Forse ricarica completamente l'HTML della tua innocente pagina web su quei teneri gattini da un file JavaScript esterno per rubare i dati della carta di credito dei tuoi utenti.

Infatti, a questo punto uno script può essere eseguito per ottenere quasi qualsiasi cosa.

Una buona Content Security Policy aiuta a fermare questo tipo di attacco, anche se la tua estensione di commenti compromessa diventa l'obiettivo del Sig. Hacker.

Lo fa perché il plugin HTTP Header di Joomla fornisce la CSP come HTTP Response Header, che dice esplicitamente al browser cosa caricare. Nelle impostazioni della scheda CSP nel plugin HTTP Headers, puoi mirare direttamente a 28 Direttive di Policy. Le direttive aiutano a proteggere il tuo sito web utilizzando solo fonti approvate per i tuoi file e contenuti.

L'esempio di attacco sopra riportato ha finito per caricare un file JavaScript da una fonte diversa per modificare l'output HTML visualizzato sullo schermo. Ciò avrebbe potuto essere evitato aggiungendo la direttiva script-src 'self' alla CSP di Joomla nel plugin.

In questo esempio, il browser caricherà i file JavaScript nel documento HTML solo se provengono dal tuo dominio. Tutti gli altri file JavaScript verranno rifiutati, compresi quelli del Signor Hacker.

Sebbene questo aiuti a proteggere il tuo sito, può anche bloccare altri file JavaScript legittimi che desideri caricare mentre la pagina web viene visualizzata sullo schermo. Questi file esterni possono essere aggiunti come fonti nella whitelist nella stessa direttiva. Per esempio, se utilizzi bootstrap da un CDN, dovresti aggiungere:

script-src 'self' https://cdn.jsdelivr.net

In questo esempio, se hai problemi a caricare bootstrap dal CDN, https://cdn.jsdelivr.net, potresti provare ad aggiungere l'URL completo del file bootstrap di cui hai bisogno. Quindi, formatteresti la tua direttiva in questo modo: script-src 'self' https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.min.js.

Aggiungere queste fonti esterne sarebbe più semplice da implementare su un nuovo sito web mentre lo costruisci. Ma se esamini il tuo HTML visualizzato con gli Strumenti per sviluppatori, dovresti essere in grado di trovare tutti i file esterni già utilizzati sul tuo sito web consolidato e includerli nella tua CSP.

Quando aggiungi direttive alla tua Content Security Policy nel plugin HTTP Headers, c'è una serie di valori del core che puoi utilizzare per definire cosa dovrebbe essere esplicitamente caricato dal browser. Questi sono quelli di base per impostare la tua prima Content Security Policy.

Altre opzioni sono disponibili per alcune delle direttive più avanzate, una lista più completa e esempi del loro utilizzo si possono trovare sul sito web della Content Security Policy (CSP) Quick Reference Guide.

• 'none' blocca l'uso di questo tipo di risorsa.
• 'self' corrisponde all'origine corrente (ma non ai sottodomini).
• 'unsafe-inline' consente l'uso di JS e CSS inline.
• 'unsafe-eval' consente l'uso di meccanismi come eval().

Quindi, diamo un'occhiata ad alcune di queste direttive. Ecco una lista di alcune delle direttive disponibili nel plugin HTTP Headers di Joomla, insieme a una breve descrizione, per gentile concessione di Content Security Policy. Ti consiglio di visitare questo sito web per ulteriori informazioni ed esempi.

default-src

La direttiva default-src definisce la policy predefinita per il recupero delle risorse come JavaScript, immagini, CSS, Font, richieste AJAX, Frame, Media HTML5.
ESEMPIO DI POLICY DEFAULT-SRC
default-src 'self' https://cdn.example.com

script-src

Definisce le fonti valide di JavaScript.
ESEMPIO DI POLICY SCRIPT-SRC
script-src 'self' https://js.example.com

style-src

Definisce le fonti valide di fogli di stile o CSS.
ESEMPIO DI POLICY STYLE-SRC
style-src 'self' css.example.com

img-src

Definisce le fonti valide di immagini.
ESEMPIO DI POLICY IMG-SRC
img-src 'self' https://img.example.com https://example.com

connect-src

Si applica a XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> o EventSource. Se non consentito, il browser emula un codice di stato HTTP 400.
ESEMPIO DI POLICY CONNECT-SRC
connect-src 'self'

font-src

Definisce le fonti valide delle risorse font (caricate tramite @font-face).
ESEMPIO DI POLICY FONT-SRC
font-src https://font.example.com https://example.com

object-src

Definisce le fonti valide di plugin, ad es. <object>, <embed> o <applet>.
ESEMPIO DI POLICY OBJECT-SRC
object-src 'self'

media-src

Definisce le fonti valide di audio e video, ad es. elementi HTML5 <audio>, <video>.
ESEMPIO DI POLICY MEDIA-SRC
media-src https://media.example.com

frame-src

Definisce le fonti valide per il caricamento dei frame. Nella CSP Level 2 frame-src è stata deprecata a favore della direttiva child-src. La CSP Level 3 ha ripristinato frame-src, che continuerà comunque a fare riferimento a child-src se non presente.
ESEMPIO DI POLICY FRAME-SRC
frame-src 'self'

sandbox

Abilita una sandbox per la risorsa richiesta, simile all'attributo sandbox dell'iframe. La sandbox applica una policy della stessa origine, impedisce i pop-up, i plugin e blocca l'esecuzione degli script. È possibile lasciare vuoto il valore sandbox per mantenere tutte le restrizioni attive, oppure aggiungere valori: allow-forms allow-same-origin allow-scripts allow-pop-ups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox e allow-top-navigation.
ESEMPIO DI POLICY SANDBOX
sandbox allow-forms allow-scripts

report-uri

Indica al browser di inviare tramite POST i report degli errori di policy a questo URI. È anche possibile usare Content-Security-Policy-Report-Only come nome dell'HTTP header per indicare al browser di inviare solo i report (senza bloccare nulla). Questa direttiva è deprecata nella CSP Level 3 a favore della direttiva report-to.
ESEMPIO DI REPORT-URI
report-uri /some-report-uri

child-src

Definisce le fonti valide per i web worker e i contesti di navigazione annidati caricati tramite elementi come <frame> e <iframe>
ESEMPIO DI POLICY CHILD-SRC
child-src 'self'

form-action

Definisce le fonti valide che possono essere usate come azione di un <form> HTML.
ESEMPIO DI POLICY FORM-ACTION
form-action 'self'

frame-ancestors

Definisce le fonti valide per incorporare la risorsa usando <frame> <iframe> <object> <embed> <applet>. Impostare questa direttiva su 'none' dovrebbe equivalere approssimativamente a X-Frame-Options: DENY. Quando questa direttiva è attiva, e se il browser la supporta, sovrascriverà le impostazioni in X-frame-options.
ESEMPIO DI POLICY FRAME-ANCESTORS
frame-ancestors 'none'

plugin-types

Definisce i tipi MIME validi per i plugin invocati tramite <object> e <embed>. Per caricare un <applet> occorre specificare application/x-java-applet.
ESEMPIO DI POLICY PLUGIN-TYPES
plugin-types application/pdf

base-uri

Definisce un insieme di URL consentiti che possono essere usati nell'attributo src di un tag base HTML.
ESEMPIO DI POLICY BASE-URI
base-uri 'self'

report-to

Definisce un nome di gruppo di segnalazione definito da un HTTP header di risposta Report-To. Per maggiori informazioni, consulta la Reporting API.
ESEMPIO DI DIRETTIVA REPORT-TO
report-to groupName

worker-src

Limita gli URL che possono essere caricati come Worker, Shared Worker o Service Worker.
ESEMPIO DI POLICY WORKER-SRC
worker-src 'none'

manifest-src

Limita gli URL da cui possono essere caricati i manifest dell'applicazione.
ESEMPIO DI POLICY MANIFEST-SRC
manifest-src 'none'

prefetch-src

Definisce le sorgenti valide per il prefetch e il prerendering delle richieste, ad esempio tramite il tag link con rel="prefetch" o rel="prerender":
ESEMPIO DI POLICY PREFETCH-SRC
prefetch-src 'none'

navigate-to

Limita gli URL verso cui il documento può navigare con qualsiasi mezzo. Ad esempio, quando si fa clic su un link, si invia un modulo o si invoca window.location. Se form-action è presente, questa direttiva viene ignorata per gli invii di moduli. Stato dell'implementazione
ESEMPIO DI POLICY NAVIGATE-TO
navigate-to https://example.com

Il plugin HTTP Headers di Joomla ti offre anche l'opportunità di impostare alcuni parametri globali nella scheda Content Security Policy.

Puoi scegliere di applicare la CSP al tuo sito web, al sito di amministrazione, o a entrambi con l'impostazione client.

L'opzione 'Report-Only' ti consente di testare le tue direttive e verificarne gli errori con gli Strumenti per sviluppatori prima di metterle in produzione. È sempre divertente rintracciare la causa degli errori CSP nella console di Google!

Successiva è l'impostazione 'Nonce'. Nonce, che significa 'numero usato una sola volta', è un sistema che applica una stringa generata casualmente a un tag <script> o <style> inline incluso nel tuo HTML tramite l'API di Joomla. Questi casi vengono solitamente implementati dagli sviluppatori di componenti / moduli / plugin di terze parti per Joomla quando installi quella funzionalità aggiuntiva sul tuo sito web.

Nell'immagine seguente, puoi vedere il tag <style> con un attributo rel nonce che è stato aggiunto ai <styles> CSS aggiunti al mio documento HTML dal componente Akeeba Backup.

È interessante notare che il codice JavaScript e CSS del core di Joomla che viene aggiunto al documento HTML attualmente non include un tag 'nonce'. Questo perché fanno parte del 'core' piuttosto che essere aggiunti tramite l'API di Joomla.

Se abiliti l'interruttore 'Nonce' nelle impostazioni CSP, consenti a quegli script e stili inline di essere renderizzati dal browser come 'sicuri'. Dovrai anche impostare il tag {nonce} di Joomla nella tua direttiva di policy script-src su script-src 'self' {nonce}. Come soluzione di riserva per i browser più vecchi che non supportano i 'nonce', puoi anche aggiungere {script-hashes} dopo il placeholder {nonce}, in questo modo script-src 'self' {nonce} {script-hashes} (presta attenzione alla spaziatura). Ma non dimenticare di abilitare prima Script Hashes.

Joomla genera casualmente la stringa di testo 'nonce' e la aggiunge ai tag <style> e <script>. Quando abiliti l'opzione 'nonce' nelle impostazioni del plugin, la stringa di testo viene passata all'HTTP Header. Il browser interpreta quindi l'HTTP Header ed elabora il corrispondente <script> o <style>. Allo stesso tempo, rimuove la stringa di testo Nonce dall'HTML renderizzato nel browser.

Questo a sua volta impedisce a Mr Hacker di dirottare la stringa nonce e aggiungerla al proprio codice iniettato. Anche se Mr Hacker riuscisse a iniettare il suo nefasto JavaScript nel tuo HTML, il browser lo bloccherà.

Script Hashes

Sappiamo tutti che non dovremmo includere JavaScript inline nel nostro HTML, dovremmo scriverlo in un file my-javascript.js e aggiungerlo all'interno di <head> o posizionarlo appena prima del tag </body>. Ma siamo tutti colpevoli di farlo di tanto in tanto.

Il problema è che se lo fai, e poi aggiungi la direttiva CSP ‘script-src 'self'’, tutto il JavaScript inline verrà bloccato per impostazione predefinita. È progettato per funzionare così, per impedire che il JavaScript iniettato da Mr Hacker possa essere eseguito sul tuo sito web.

C'è una sostituzione per questo con la direttiva script-src 'unsafe-inline', che permetterà al JavaScript inline di Mr Hacker di essere eseguito, insieme al tuo codice affidabile. Questa non è l'opzione migliore, per ovvi motivi.

Gli Script Hashes vengono in soccorso!

Il plugin HTTP Headers di Joomla raccoglie automaticamente tutti gli <styles> e <scripts> passati tramite l'API di Joomla nel sito. Genera quindi i rispettivi hash e li passa tramite l'HTTP Header. Il browser genera poi gli hash sul sito stesso e conferma che gli hash corrispondano. Se corrispondono, gli script vengono eseguiti, altrimenti vengono bloccati.

Per abilitare questa funzione del plugin, attiva l'interruttore su 'Abilitato'. Poi, nella tua direttiva di policy script-src aggiungi il valore 'self' {script-hashes}. Se stai usando la funzione 'nonce', insieme a 'script hashes', imposta il valore della direttiva come nell'esempio del nonce sopra.

Ecco, questo sì che è intelligente.

Ma la cosa ancora migliore è che possiamo usare la stessa idea per elaborare gli script hashes manualmente e aggiungerli alla nostra direttiva script-src 'self'. Richiederà un po' di lavoro da impostare e mantenere, ma potrebbe salvarti se hai aggiunto del JavaScript a un articolo o a un modulo personalizzato.

Esistono modi più dettagliati per farlo usando un generatore di hash sha256, sha384 o sha512. Ma poiché la maggior parte delle persone aggiungerà solo piccoli frammenti di JavaScript al proprio articolo o modulo personalizzato, lasceremo che siano gli Strumenti per sviluppatori di Google a fare il lavoro per noi.

Il processo è semplice. L'unica differenza è come generiamo l'hash.

Supponendo che tu abbia abilitato il plugin HTTP Headers di Joomla, che il CSP sia attivo e che tu abbia impostato e salvato la direttiva script-src 'self'.

Passo 1 - Aggiungi il tuo JavaScript inline al tuo articolo o modulo personalizzato e salvalo. Non dimenticare di modificare le impostazioni del tuo editor per impedire che quest'ultimo rimuova il tuo codice durante il salvataggio.

Passo 2 - Naviga fino alla tua pagina web contenente il tuo script. Apri gli Strumenti per sviluppatori e nella scheda console vedrai un errore simile a:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='), or a nonce ('nonce-...') is required to enable inline execution.

Passo 3 - Ora, tutto ciò che devi fare è copiare/incollare l'hash dal messaggio di errore nella tua direttiva JavaScript nel plugin e salvare di nuovo:

script-src 'self' 'sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='

Successivamente, ricarica la tua pagina web e controlla di nuovo negli Strumenti per sviluppatori di Google. L'errore ora sarà scomparso e il browser caricherà il tuo script sulla pagina web.

Nota: C'è ancora un errore mostrato nel mio esempio poiché il JavaScript aggiunto al mio articolo non è completo. Tuttavia, dimostra che il codice inline sta almeno cercando di funzionare.

Aggiungere hash al proprio codice inline è un buon modo per inserirli nella whitelist dell'HTTP header in modo che vengano comunque eseguiti, mentre qualsiasi codice inline non esplicitamente sottoposto ad hash e aggiunto al tuo CSP verrà comunque bloccato. Contrastando così il tentativo del Signor Hacker di compromettere il tuo sito.

Nota:

Se modifichi il tuo JavaScript, dovrai ricalcolare il tuo hash e modificare il valore nella direttiva CSP.

Se riscontri problemi nel far funzionare i tuoi hash, ci sono 3 problemi comuni, puoi trovare le soluzioni nella pagina web Using a hash with CSP.

Strict Dynamic

Se abiliti l'opzione Strict Dynamic nel tuo CSP, questa prenderà l'autorità esplicita che hai concesso a uno script tramite un Hash, o Nonce, e la applicherà a qualsiasi altro script direttamente collegato ad esso, o chiamato da esso. Questa azione sovrascrive anche le direttive predefinite come 'self' o 'unsafe-inline' applicate nelle tue direttive CSP generali a questi script figli. Verranno ignorate.

Style Hashes

Lo Style Hash del CSP funziona esattamente nello stesso modo degli hash JavaScript descritti sopra, ma usalo se aggiungi blocchi CSS <style> nel corpo del tuo HTML. Proprio come con 'Script Hashes', Abilita la funzionalità del plugin e imposta una Direttiva di Policy style-src per farvi riferimento con il valore 'self' {style-hashes}.

Nota:

Se modifichi il tuo CSS inline, piuttosto che il CSS creato dalle API di Joomla, dovrai ricalcolare il tuo hash e modificare il valore nella direttiva CSP.

Frame Ancestors 'self'

Questa opzione nel plugin consente a una pagina di essere incorniciata, ad esempio, all'interno di un iframe, ma solo dallo stesso sito.

Se vuoi consentire esplicitamente a un sito web diverso di incorniciare i tuoi contenuti, puoi impostare una direttiva specifica 'frame-src'.

Nota finale / Conclusione:

Scrivendo questo articolo, mi sono reso conto di aver solo sfiorato la superficie di questo enorme argomento.

Adoro scoprire argomenti che prima avevo ignorato, o che non conoscevo. Anche tu sei così?

La conclusione a cui sono giunto ricercando l'argomento degli HTTP Headers, e in particolare utilizzando il nuovo plugin J4 di Joomla per impostarli, è che tutti dobbiamo padroneggiare questo argomento. Ci sono fin troppe persone (hacker) là fuori che aspettano solo un'opportunità per approfittare di siti web con una sicurezza debole. Quindi, non aiutare i tuoi utenti a diventare vittime.

Divertiti a esplorare il plugin HTTP Headers di Joomla e scopri come può aiutare a proteggere il tuo sito web.

Ti consiglio comunque di approfondire un po' di più questo interessante argomento prima di iniziare. Qui sotto trovi dei link per avviare le tue ricerche. Capirai molto meglio come funziona internet e come il tuo sito web interagisce con esso.

Per riferimento

Se devi resettare il plugin, il plugin HTTP Headers è stato installato con le seguenti opzioni impostate:

Il plugin è abilitato per impostazione predefinita.

• Le schede HSTS e CSP sono disabilitate per impostazione predefinita.
• X-Frame-Options è abilitato per impostazione predefinita.
• Referrer-Policy è inizialmente impostato su: strict-origin-when-cross-origin.
• Cross-Origin-Opener-Policy è inizialmente impostato su same-origin.

Se sei arrivato fin qui pensando "Non è giusto, e J3?", "Perché non possiamo avere le stesse funzionalità in Joomla 3?". Beh, la buona notizia è che puoi. Anche se dovrai scaricare il plugin dalla JED.

Quando avrai configurato i tuoi HTTP headers con il plugin di Joomla 4, potrai testare i tuoi HTTP Headers sul sito web Security Headers.

Che punteggio hai ottenuto?

Tieni presente che l'attivazione del plugin HTTP Headers potrebbe avere effetti inaspettati sul frontend.

Infine, vorrei ringraziare Tobias Zulauf e Ced Keiflin per il loro contributo nel completare questo articolo in tempo!