Indice dei contenuti dell'articolo:
HTTP Strict Transport Security (HSTS) è un meccanismo di criteri di sicurezza Web che consente ai siti Web di dichiararsi accessibili solo tramite connessioni sicure. Ciò aiuta a proteggere i siti Web e gli utenti dal downgrade del protocollo e dagli attacchi di dirottamento dei cookie.
L’HTTP Strict Transport Security (HSTS) ha una storia affascinante che risale al 2008. Tutto ha avuto inizio con un documento di ricerca chiamato “Forced HTTPS: Protecting High-Security Web Sites from Network Attacks“, scritto da Collin Jackson e Adam Barth. Questo lavoro innovativo ha gettato le basi per quello che sarebbe diventato HSTS, delineando l’idea fondamentale di costringere le connessioni a siti web ad utilizzare HTTPS per migliorare la sicurezza.
In seguito, il 18 settembre 2009, un’evoluzione significativa ha avuto luogo quando PayPal, insieme a Jackson e Barth, ha pubblicato una versione rivista dello schema del protocollo contenuto nel documento originale. Questo documento aggiornato, che è disponibile online, ha rappresentato un passo in avanti nella definizione di quello che sarebbe diventato HSTS.
La successiva fase cruciale nella storia di HSTS è avvenuta il 18 dicembre 2009, quando è stata rilasciata l’ultima “versione comunitaria” della specifica “STS” allora denominata. Questa versione ha incorporato le modifiche basate sul feedback ricevuto dalla comunità di esperti di sicurezza di Internet, perfezionando ulteriormente le linee guida per l’uso di HSTS.
Infine, la specifica formale di HSTS (RFC 6797) è stata pubblicata il 19 novembre 2012, dopo essere stata approvata il 2 ottobre 2012 dall’Internet Engineering Steering Group (IESG), un organismo composto dal presidente della Internet Engineering Task Force (IETF) e dai vari direttori di area. Questa approvazione ha segnato l’ufficializzazione di HSTS come standard di sicurezza per le connessioni a siti web, confermando il suo ruolo chiave nella protezione degli utenti da vari attacchi di rete.
Perché è stato introdotto l’HSTS?
Il protocollo HTTP (Hypertext Transfer Protocol) è un protocollo di comunicazione ampiamente utilizzato per la trasmissione di informazioni sulla rete internet. Questo protocollo si appoggia su vari sistemi di trasporto, il più comune dei quali è il Transmission Control Protocol (TCP). TCP è il pilastro fondamentale del sistema di trasporto e garantisce la consegna affidabile dei dati tra sistemi interconnessi.
Tuttavia, TCP ha una lacuna significativa: non offre alcuna protezione dell’integrità dei dati, riservatezza delle informazioni o identificazione sicura dell’host. In altre parole, le informazioni trasmesse tramite TCP sono vulnerabili alle intercettazioni non autorizzate, all’alterazione dei dati e alla falsa identificazione.
Questa carenza di sicurezza ha motivato la creazione di protocolli aggiuntivi per migliorare la sicurezza dei dati durante la trasmissione. Il Secure Sockets Layer (SSL) e il suo successore, il Transport Layer Security (TLS), sono nati proprio con questo obiettivo. Questi protocolli forniscono un livello di crittografia che agisce come uno scudo tra i protocolli applicativi e TCP. L’uso combinato di HTTP e SSL/TLS dà origine a quello che comunemente chiamiamo HTTPS, o HTTP sicuro.
Gli user agent, come i browser web, utilizzano varie politiche di sicurezza locali per decidere come interagire con un host. Questa decisione si basa su una serie di fattori, tra cui la negoziazione tra il server e l’user agent, le preferenze dell’utente e il metodo di comunicazione utilizzato (HTTP o HTTPS).
Tuttavia, in alcune circostanze, gli utenti possono scegliere di continuare a interagire con un sito web anche quando non riescono a stabilire una connessione sicura. Questo può succedere quando la catena di fiducia di un certificato TLS non viene convalidata, quando il certificato è scaduto, o quando il nome di dominio dell’host TLS viene visualizzato in modo errato nel certificato. Questa pratica è conosciuta come “insicurezza click-through”.
Sebbene questa possibilità possa sembrare conveniente per l’utente, introduce potenziali rischi di sicurezza. Gli utenti che decidono di continuare a utilizzare un sito web senza una connessione sicura HTTPS diventano vulnerabili a vari tipi di attacchi informatici. Tra questi, spiccano gli attacchi man-in-the-middle (MITM), in cui un aggressore intercetta e potenzialmente altera la comunicazione tra due parti, gli attacchi di downgrade, che forzano una connessione a utilizzare un protocollo meno sicuro, e gli attacchi di dirottamento della sessione, in cui un aggressore prende il controllo della sessione di un utente.
SSL-stripping
HTTP Strict Transport Security (HSTS) è un meccanismo di sicurezza che consente ai siti web di dichiarare che sono accessibili esclusivamente tramite una connessione sicura. Questo significa che un sito web può impedire agli utenti di connettersi a esso attraverso qualsiasi connessione non sicura, come quelle basate sul protocollo HTTP. Questa misura protegge efficacemente gli utenti da una vulnerabilità di sicurezza ben nota denominata SSL-stripping.
Lo SSL-stripping è un tipo di attacco di downgrade, una forma particolarmente insidiosa di attacco crittografico a un sistema informatico o, come in questo caso, a un protocollo di comunicazione. L’attacco di downgrade costringe il sistema o il protocollo a rinunciare alla sua connessione crittografata (HTTPS) e ad adottare invece una connessione non crittografata (HTTP) più datata, che è generalmente mantenuta attiva per la retrocompatibilità con i sistemi più vecchi.
Lo stripping SSL è stato presentato per la prima volta da Moxie Marlinspike nel suo intervento al congresso BlackHat del 2009, intitolato “New Tricks for Defeating SSL in Practice”. Questo attacco viene implementato come parte di un attacco man-in-the-middle, in cui il traffico web viene intercettato e deviato dalla versione HTTPS sicura del sito web a una versione HTTP non crittografata.
Un fattore principale che permette a questo tipo di attacco di continuare ad avere successo è che molti siti web non utilizzano i certificati TLS/SSL. Di conseguenza, è impossibile determinare (senza una conoscenza preliminare) se l’assenza di HTTPS in un sito web è dovuta a un attacco di stripping SSL o al fatto che il sito non disponga di un certificato TLS.
Un aspetto particolarmente allarmante di questo attacco è che non ci sono segnali o avvisi che possono avvertire l’utente durante il processo di downgrade. Questo rende l’attacco difficile da rilevare anche per l’utente più attento e consapevole dei rischi di sicurezza.
La creazione da parte di Marlinspike di uno strumento per automatizzare completamente questo tipo di attacco rende l’SSL-stripping un serio rischio per la sicurezza informatica. La minaccia rappresentata da questi attacchi mette in evidenza l’importanza di adottare misure di sicurezza adeguate, come l’utilizzo di HSTS, per garantire l’integrità e la sicurezza delle comunicazioni online.
Dirottamento della sessione – Session Hijacking
Il dirottamento della sessione, noto anche come session hijacking o dirottamento dei cookie, è un tipo di vulnerabilità di sicurezza che può essere sfruttata attraverso l’insicurezza del click-through, un comportamento che consente agli utenti di continuare a interagire con un sito web nonostante la mancanza di una connessione sicura HTTPS.
In un attacco di dirottamento della sessione, un aggressore sfrutta una sessione valida tra un computer e un server per ottenere l’accesso non autorizzato a informazioni o servizi. Questo tipo di attacco è particolarmente rilevante per gli sviluppatori web, dato che i cookie, piccoli file di testo salvati sul dispositivo dell’utente, vengono utilizzati per mantenere lo stato della sessione su molti siti web.
Se un sito web non contrassegna i propri cookie come sicuri, indicando agli user agent, come i browser web, di inviare i cookie solo attraverso una connessione HTTPS, questi possono essere facilmente intercettati e rubati da un utente malintenzionato. I cookie non protetti, infatti, vengono inviati all’host indipendentemente dalla sicurezza del canale di trasporto utilizzato, il che li rende vulnerabili a attacchi man-in-the-middle. Questi attacchi avvengono quando un aggressore riesce a intercettare e potenzialmente manipolare la comunicazione tra due parti senza che nessuna delle due ne sia consapevole.
Una volta che un utente malintenzionato ha ottenuto accesso ai cookie, può impersonare l’utente originale su un sito web legittimo, sfruttando le credenziali di sessione salvate nel cookie per accedere alle risorse protette del sito come se fosse l’utente legittimo. Questo tipo di attacco può avere conseguenze gravi, compreso l’accesso non autorizzato a informazioni personali, finanziarie o sensibili dell’utente.
È importante notare che, per prevenire il dirottamento della sessione, è fondamentale che i siti web utilizzino connessioni sicure HTTPS e contrassegnino i propri cookie come sicuri, in modo che questi vengano inviati solo attraverso connessioni crittografate. Inoltre, gli utenti dovrebbero essere consapevoli dei rischi associati all’insicurezza del click-through e dovrebbero evitare di accettare connessioni non sicure quando possibile.
Come funziona l’HSTS?
HTTP Strict Transport Security (HSTS) è un protocollo di sicurezza che consente ai server web di dichiarare che tutte le interazioni tra un browser web o altri programmi utente devono essere svolte su connessioni HTTPS, che offrono una crittografia sicura, invece delle non protette connessioni HTTP.
Un server può implementare una politica HSTS fornendo un’intestazione di risposta specifica su una connessione HTTPS. Tale intestazione, denominata Strict-Transport-Security, specifica un periodo di tempo durante il quale l’interprete, come un browser web, deve accedere al servizio esclusivamente tramite richieste HTTPS. È importante notare che le intestazioni HSTS inviate attraverso le risposte HTTP non sicure vengono ignorate per evitare la possibilità di manipolazione malevola.
Il funzionamento di HSTS è relativamente semplice. La prima volta che un utente accede a un sito tramite HTTPS e il sito restituisce l’intestazione Strict-Transport-Security, il browser registra queste informazioni. Quindi, i tentativi futuri di caricare il sito tramite HTTP verranno automaticamente reindirizzati a HTTPS, garantendo così una connessione sicura.
Una volta trascorso il periodo di tempo specificato dall’intestazione Strict-Transport-Security, il successivo tentativo di caricare il sito tramite HTTP procederà come di consueto, anziché essere automaticamente reindirizzato a HTTPS. Tuttavia, ogni volta che l’intestazione Strict-Transport-Security viene fornita all’agente utente, questa aggiornerà il periodo di validità per quel sito. Di conseguenza, i siti possono continuare a inviare queste intestazioni per prevenire la scadenza della politica HSTS.
Nel caso in cui fosse necessario disabilitare HSTS, i server web possono impostare il valore di massima età a zero su una connessione HTTPS. Ciò farà scadere immediatamente l’intestazione HSTS, consentendo così l’accesso tramite richieste HTTP.
Un esempio di come funziona HSTS potrebbe essere un server che invia un’intestazione che richiede che tutte le richieste future per il prossimo anno utilizzino solo HTTPS. Questo può essere realizzato tramite l’intestazione Strict-Transport-Security: max-age=31536000.
Quando un’applicazione web invia una politica HSTS agli user agent, gli user agent conformi modificano automaticamente tutti i collegamenti non sicuri in collegamenti sicuri. Ad esempio, un link come http://example.com/ verrebbe trasformato in https://example.com prima di raggiungere il server. Inoltre, se non è possibile stabilire una connessione sicura, ad esempio perché il server non dispone di un certificato valido, l’agente utente interromperà la connessione e non consentirà all’utente di accedere al sito web.
L’aspetto più importante di HSTS è che impedisce l’insicurezza del click-through, non consentendo all’utente di utilizzare la connessione non sicura. Questo serve a proteggere gli utenti da vari tipi di attacchi informatici, come attacchi man-in-the-middle, attacchi di downgrade e dirottamenti della sessione.
Qual è un esempio di situazione che coinvolge HSTS?
Consideriamo un esempio pratico che illustra l’importanza e l’efficacia dell’HTTP Strict Transport Security (HSTS). Supponiamo che un membro del tuo team decida di utilizzare un punto di accesso Wi-Fi gratuito in un bar per navigare sul web. Durante la sua sessione di navigazione, decide di accedere al sistema di buste paga della tua organizzazione per verificare i dettagli del suo stipendio.
Sfortunatamente, il punto di accesso Wi-Fi a cui si è collegato non è sicuro. È gestito da un hacker che ha impostato il suo laptop per intercettare le richieste HTTP in transito. Quando il tuo dipendente cerca di accedere al sistema di buste paga, l’hacker intercetta la richiesta HTTP originale e reindirizza il tuo dipendente a un sito web fasullo, una copia perfetta del tuo sistema di gestione stipendi. Questo porta all’esposizione delle informazioni personali identificabili (PII) dei tuoi dipendenti, creando un problema significativo di privacy e sicurezza.
Tuttavia, se il tuo sistema di gestione stipendi utilizza HSTS e il tuo dipendente ha precedentemente visitato il sito utilizzando una connessione HTTPS, il suo browser ricorderà di utilizzare esclusivamente connessioni HTTPS per quel sito in futuro. Ciò significa che non importa quanto l’hacker tenti di reindirizzare il traffico del tuo dipendente a un sito web fasullo tramite una connessione HTTP non sicura, il browser del dipendente insisterà per utilizzare solo HTTPS.
In questo modo, l’uso dell’HSTS protegge efficacemente il tuo dipendente e il tuo sistema di gestione stipendi da potenziali attacchi man-in-the-middle. A dimostrazione di quanto sia cruciale per le organizzazioni garantire che i loro siti web implementino adeguatamente il protocollo HSTS, al fine di mantenere la sicurezza e la privacy dei loro utenti e dei loro dati.
Quali sono i limiti dell’HSTS?
L’HTTP Strict Transport Security (HSTS) è un potente strumento per garantire la sicurezza delle connessioni web, ma presenta anche alcuni limiti fondamentali.
Il primo è che un utente che non è in grado di stabilire una connessione HTTPS sicura non potrà accedere al sito web che implementa HSTS. Questo può creare problemi di accessibilità in circostanze dove le connessioni HTTPS sono problematiche o non disponibili.
Inoltre, la comunicazione della politica HSTS avviene tramite un’intestazione di risposta HTTP, il che significa che l’utente deve prima visitare il sito web per scoprire che esso utilizza HSTS. Questo implica che la prima richiesta al sito web, se fatta attraverso un protocollo non sicuro come HTTP, rimane vulnerabile agli attacchi attivi. Lo stesso si applica alla prima richiesta dopo la scadenza del periodo specificato nella direttrice “max-age” dell’HSTS. Questo periodo è solitamente impostato a durare per diversi giorni o mesi, a seconda delle esigenze specifiche del sito e del comportamento dell’utente.
Per mitigare questo problema, molti browser supportano il “precaricamento” dei criteri HSTS. Questo significa che mantengono un elenco di siti web noti per utilizzare HSTS e utilizzano automaticamente una connessione HTTPS per la prima richiesta a questi siti. Tuttavia, questo approccio non è scalabile a tutto il web. Ci sono state discussioni sul possibile utilizzo dei record DNS e del DNSSEC per dichiarare e garantire l’utilizzo di HSTS, il che potrebbe offrire una soluzione più generale.
Un’altra limitazione di HSTS è la sua inefficacia contro certi tipi di attacchi. Non protegge, per esempio, contro gli attacchi di typosquatting, basati su DNS o attacchi man-in-the-middle che utilizzano domini falsi che non sono inclusi nell’elenco di precaricamento HSTS del browser.
Infine, poiché HSTS dipende dal protocollo TLS, la sua sicurezza è legata alla robustezza di TLS. Se ci sono vulnerabilità in TLS, HSTS sarà indirettamente colpito.
Per una discussione più dettagliata e tecnica su questi e altri aspetti di HSTS, si consiglia di consultare il Request for Comments (RFC) 6797.
Preloading HSTS
Il “Preloading” di HSTS è un metodo utilizzato per migliorare la sicurezza dei siti web e superare una delle principali limitazioni di HSTS – il fatto che l’utente deve aver visitato precedentemente il sito prima che la politica HSTS sia rispettata. Il preloading HSTS risolve questo problema includendo il sito web in un elenco predefinito di siti che utilizzano HSTS, distribuito con il browser. In questo modo, quando un utente visita per la prima volta il sito, il browser sa già che deve usare HTTPS, evitando così il problema del “primo contatto”.
hstspreload.org è un servizio che consente ai proprietari di siti web di richiedere l’inclusione del proprio sito nell’elenco di precaricamento HSTS distribuito con i principali browser. Per essere incluso in questo elenco, un sito web deve soddisfare una serie di criteri specificati, tra cui l’invio di un’intestazione HSTS corretta con un valore “max-age” di almeno 31536000 secondi (circa un anno), e l’inclusione della direttiva “includeSubDomains” e “preload”.
Per configurare un server web NGINX per inviare le intestazioni corrette e soddisfare questi criteri, è necessario aggiungere la seguente configurazione all’interno del blocco “server” nel file di configurazione di NGINX:
server {
# ... altre configurazioni del server ...
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# ... altre configurazioni del server ...
} Una volta implementata questa configurazione, è possibile richiedere l’inclusione del sito (nel nostro esempio, esempio.it) nell’elenco di precaricamento HSTS attraverso hstspreload.org. Basta inserire il dominio del sito nel campo di input fornito e seguire le istruzioni fornite. Il sito verrà quindi controllato per assicurarsi che soddisfi tutti i criteri necessari, e se tutto va bene, sarà aggiunto all’elenco.
Il processo di preloading HSTS non avviene in tempo reale, ma piuttosto in concomitanza con ogni nuova release di Google Chrome. Questo perché l’elenco predefinito di siti che utilizzano HSTS è incluso in ogni versione del browser Google Chrome. Una volta che un sito web ha richiesto e soddisfatto i requisiti per l’inclusione attraverso hstspreload.org, il sito viene aggiunto all’elenco e questa modifica viene inclusa nella prossima versione di Google Chrome.
Tuttavia, è importante notare che ci potrebbe essere un periodo di attesa significativo prima che l’inclusione diventi effettiva. Google rilascia nuove versioni di Chrome ogni sei settimane circa, ma ci potrebbe essere un ulteriore ritardo prima che la modifica venga incorporata nel browser. Questo perché ci potrebbero essere molte richieste di inclusione in attesa e il processo di revisione e aggiunta all’elenco richiede tempo.
Nel complesso, si dovrebbe prevedere che ci vogliano almeno due o tre mesi affinché un sito venga incluso nell’elenco predefinito di Chrome dopo la richiesta iniziale. Tuttavia, una volta inclusi nell’elenco, tutti i visitatori del sito web che utilizzano una versione di Chrome aggiornata beneficeranno dei vantaggi della politica HSTS dal loro primo contatto con il sito.
Preloading HSTS e miglioramento performance e valori del TTFB.
Il preloading di HSTS (HTTP Strict Transport Security) non solo migliora la sicurezza generale del sito web, ma può anche contribuire a migliorare le prestazioni complessive del sito e ridurre il Tempo di Prima Byte (TTFB). Il TTFB è un parametro che misura il tempo che trascorre dal momento in cui un client (ad esempio, un browser web) invia una richiesta HTTP fino al momento in cui riceve il primo byte della risposta dal server web. La riduzione del TTFB può migliorare notevolmente la velocità complessiva di caricamento di una pagina web e l’esperienza dell’utente.
Con HSTS abilitato e configurato per il preloading, il browser dell’utente sa in anticipo che deve comunicare con il sito web solo attraverso una connessione sicura HTTPS, eliminando quindi la necessità di un reindirizzamento HTTP a HTTPS. Questo reindirizzamento può introdurre latenze addizionali che aumentano il TTFB.
Senza HSTS, il browser dell’utente potrebbe inizialmente tentare di stabilire una connessione non sicura HTTP, che il server reindirizza poi a una connessione HTTPS. Questo reindirizzamento richiede tempo e rallenta il caricamento della pagina.
Con il preloading di HSTS, questo reindirizzamento viene evitato, il che può portare a una riduzione del TTFB, rendendo il sito web più veloce e più reattivo. Questo è un beneficio particolarmente significativo per i siti web ad alte prestazioni, dove anche miglioramenti minimi nel TTFB possono avere un impatto notevole sull’esperienza dell’utente e sulla velocità complessiva del sito.
Quali sono le best practice per la distribuzione di HSTS?
Le best practice per la distribuzione di HTTP Strict Transport Security (HSTS) sono pensate per ottimizzare la sicurezza del tuo sito e garantire che tutti i visitatori del tuo sito beneficino della protezione offerta da HSTS. Qui ci concentreremo su come eseguire correttamente la distribuzione di HSTS se il tuo sito è vincolato a HTTPS e intendi precaricare HSTS. I seguenti passaggi delineano il processo:
- Assicurati di fornire un certificato valido: Un certificato SSL/TLS valido è essenziale per stabilire una connessione HTTPS sicura. Ciò implica che il certificato deve essere emesso da un’autorità di certificazione (CA) riconosciuta e che il nome del tuo sito deve corrispondere al nome specificato nel certificato.
- Reindirizza da HTTP a HTTPS sullo stesso host, se sei in ascolto sulla porta 80: Questo passaggio è fondamentale per garantire che tutte le connessioni al tuo sito siano sicure. Tutte le richieste HTTP dovrebbero essere reindirizzate a HTTPS sullo stesso host.
- Serve tutti i sottodomini su HTTPS: Assicurati che tutti i sottodomini del tuo sito utilizzino HTTPS per garantire la sicurezza delle connessioni in tutto il tuo dominio.
- Supporta HTTPS per il sottodominio www se esiste un record DNS per quel sottodominio: Se il tuo sito ha un record DNS per un sottodominio www, questo deve supportare HTTPS.
- Serve un’intestazione HSTS nel dominio di base per le richieste HTTPS: L’intestazione deve specificare un’età massima di almeno 31536000 secondi (1 anno), deve includere la direttiva includeSubDomains e la direttiva preload.
- Se stai servendo un reindirizzamento aggiuntivo dal tuo sito HTTPS, quel reindirizzamento deve ancora avere l’intestazione HSTS.
Per raggiungere un livello di sicurezza ottimale, si consiglia di seguire i seguenti passaggi:
- Inizia esaminando tutti i sottodomini e i sottodomini nidificati del tuo sito per garantire che funzionino su HTTPS.
- Successivamente, abilita HSTS per tutte le risposte HTTPS e aumenta progressivamente l’età massima. Durante ogni fase, monitora attentamente le metriche del tuo sito, risolvi eventuali problemi che si verificano e attendi l’età massima della fase prima di procedere. Puoi seguire la seguente progressione per l’età massima dell’intestazione: 5 minuti, 1 settimana, 1 mese.
- Una volta che sei sicuro che non ci sono problemi, aumenta l’età massima a 2 anni e invia il tuo sito all’elenco di precaricamento HSTS con la direttiva di precaricamento.
Infine, puoi inviare il tuo sito web per l’inclusione nell’elenco di precaricamento HSTS tramite hstspreload.org. Questo sito è gestito dal team del progetto Chromium e fornisce un modo per i siti web di essere inclusi nell’elenco di precaricamento HSTS distribuito con Chrome e altri browser basati su Chromium
Quali browser supportano HSTS?
HSTS (HTTP Strict Transport Security) gode di un ampio supporto tra i principali browser, a conferma del suo ruolo fondamentale nell’aumentare la sicurezza delle connessioni internet.
Chromium e Google Chrome sono stati tra i primi browser a supportare HSTS, a partire dalla versione 4.0.211.0. Questo ha segnato un importante passo avanti nell’implementazione di misure di sicurezza avanzate per proteggere gli utenti di internet da potenziali attacchi.
Firefox ha iniziato a supportare HSTS a partire dalla versione 4. Ma con l’introduzione di Firefox 17, Mozilla ha fatto un ulteriore passo in avanti integrando un elenco di siti web che supportano HSTS, migliorando ulteriormente la sicurezza degli utenti.
Opera, a partire dalla versione 12, ha iniziato a supportare HSTS, riconoscendo l’importanza di fornire una connessione sicura ai suoi utenti.
Safari ha iniziato a supportare HSTS a partire da OS X Mavericks, versione 10.9. Questo ha fornito un livello di protezione aggiuntivo per gli utenti di Safari, aiutandoli a navigare in internet in modo più sicuro.
Internet Explorer 11 su Windows 8.1 e Windows 7 ha iniziato a supportare HSTS quando è stato installato l’aggiornamento KB 3058515. Questo ha permesso ai suoi utenti di beneficiare delle protezioni offerte da HSTS.
Microsoft Edge e Internet Explorer 11 su Windows 10 supportano HSTS, rafforzando ulteriormente la sicurezza di questi browser.
Infine, anche il BlackBerry 10 Browser e WebView supportano HSTS, a partire da BlackBerry OS 10.3.3. Questo conferma l’importanza di HSTS non solo per i desktop, ma anche per i dispositivi mobili.
Conclusioni
Riassumendo brevemente, HTTP Strict Transport Security (HSTS) è un importante meccanismo di sicurezza che aiuta a proteggere i siti web e i loro utenti da vari tipi di attacchi, tra cui attacchi man-in-the-middle. Funziona costringendo i browser a utilizzare connessioni sicure HTTPS con i siti web che implementano la politica HSTS.
Tuttavia, l’HSTS ha alcune limitazioni. Richiede che l’utente visiti prima il sito web per apprendere la sua politica HSTS, il che può lasciare la prima richiesta esposta a potenziali attacchi. Questo è dove entra in gioco il preloading di HSTS. Il preloading di HSTS permette ai siti web di essere inclusi in un elenco di siti HSTS che viene distribuito con i browser, eliminando così la necessità per l’utente di visitare prima il sito per scoprire la sua politica HSTS.
La configurazione del preloading di HSTS richiede alcuni passaggi, tra cui l’impostazione di intestazioni specifiche e la presentazione del sito all’elenco di preloading di HSTS. Anche se può essere un po’ complesso da configurare, offre un livello di sicurezza aggiuntivo che vale la pena di considerare.
Inoltre, il preloading di HSTS può anche migliorare le prestazioni del sito web riducendo il Tempo di Prima Byte (TTFB), il che può portare a una migliore esperienza utente.
Infine, HSTS ha una vasta compatibilità con i browser, inclusi Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera, Safari e BlackBerry 10 Browser.
