23 Settembre 2022

Che cos’è HSTS, HTTP Strict Transport Security ?

HTTP Strict Transport Security è un meccanismo di criteri di sicurezza Web che consente ai siti Web di dichiararsi accessibili solo tramite connessioni sicure.

HSTS
Print Friendly, PDF & Email

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.

Perché è stato introdotto l’HSTS?

HTTP viene utilizzato su vari trasporti, in genere il Transmission Control Protocol (TCP).

Tuttavia, TCP non fornisce protezione dell’integrità, riservatezza o identificazione sicura dell’host.

Ciò ha portato allo sviluppo di Secure Sockets Layer (SSL) e del suo successore Transport Layer Security (TLS). SSL/TLS fornisce un livello di crittografia tra i protocolli applicativi e TCP, comunemente noto come HTTPS .

In generale, gli user agent (come i browser web) utilizzeranno varie politiche di sicurezza locali per decidere come interagire con un host, sulla base di una negoziazione tra il server, le preferenze dell’utente e il loro metodo di comunicazione (HTTP o HTTPS).

Tuttavia, alcuni programmi utente consentono agli utenti di scegliere di continuare a interagire con un sito Web quando non sono in grado di stabilire una connessione sicura. Ciò potrebbe verificarsi quando la catena di attendibilità di un certificato TLS non viene convalidata, quando è scaduta o quando il nome di dominio dell’host TLS viene visualizzato in modo errato nel certificato TLS.

Questo comportamento è chiamato insicurezza click-through.

Pur offrendo agli utenti la possibilità di continuare a utilizzare un sito Web nonostante la mancanza di HTTPS possa soddisfare gli utenti, può introdurre  vettori di attacco  che lasciano gli utenti aperti a determinati tipi di  attacchi informatici , in particolare  attacchi man-in-the-middle (attacchi MITM) , attacchi di downgrade e attacchi di dirottamento della sessione.

SSL-stripping

Poiché HSTS consente ai siti Web di dichiarare che sono accessibili solo tramite una connessione sicura, possono impedire agli utenti di connettersi a loro tramite qualsiasi connessione HTTP.

Ciò impedisce una vulnerabilità di sicurezza nota come SSL-stripping.

Lo stripping SSL è un attacco di downgrade introdotto da  Moxie Marlinspike  nel suo discorso federale BlackHat del 2009  New Tricks for Defeating SSL in Practice .

Un attacco di downgrade è una forma di attacco crittografico a un sistema informatico o, in questo caso, un protocollo di comunicazione che fa abbandonare la sua  connessione crittografata  (HTTPS) a favore di una connessione non crittografata (HTTP) più vecchia che viene generalmente fornita per la retrocompatibilità con sistemi più vecchi.

Lo stripping SSL viene implementato come parte di un attacco man-in-the-middle in cui il traffico Web viene intercettato e reindirizzato dalla versione HTTPS sicura del sito Web a una versione HTTP non crittografata.

Il motivo principale per cui questo attacco continua ad avere successo è che molti siti Web continuano a non utilizzare i certificati TLS/SSL. Ciò rende impossibile sapere (senza una conoscenza preliminare) se la mancanza di HTTPS in un sito Web è dovuta a un attacco di stripping SSL o perché non dispongono di un certificato TLS.

Inoltre, non ci sono avvisi per avvisare l’utente durante il processo di downgrade, rendendo l’attacco difficile da rilevare anche per l’utente più vigile.

Con la creazione di uno strumento da parte di Marlinspike per automatizzare completamente questo tipo di attacco, rappresenta un vero e proprio  rischio per la sicurezza informatica .

Dirottamento della sessione – Session Hijacking

Il dirottamento della sessione o il dirottamento dei cookie è un’altra vulnerabilità abilitata dall’insicurezza del click-through.

Il dirottamento della sessione sfrutta una sessione valida del computer per ottenere l’accesso non autorizzato a informazioni o servizi.

Ciò è particolarmente rilevante per gli sviluppatori Web poiché i cookie vengono utilizzati per mantenere una sessione su molti siti Web.

Se un sito Web non contrassegna i propri cookie come Sicuri, dicendo agli user agent di inviare cookie solo tramite HTTPS, possono essere facilmente rubati da un utente malintenzionato. Poiché i cookie non protetti vengono restituiti all’host indipendentemente dalla sicurezza del trasporto, lasciandoli aperti ad attacchi man-in-the-middle.

Una volta che un utente malintenzionato ha accesso ai cookie, può quindi impersonare l’utente su un sito Web legittimo.

Come funziona l’HSTS?

HSTS consente ai server Web di dichiarare che qualsiasi interazione da parte di browser Web e altri programmi utente deve essere condotta su connessioni HTTPS e non connessioni HTTP non sicure.

Un server può implementare una politica HSTS fornendo un’intestazione di risposta su una connessione HTTPS (le intestazioni HSTS inviate tramite le intestazioni di risposta HTTP vengono ignorate). L’intestazione HSTS è denominata Strict-Transport-Security e specifica anche un periodo di tempo durante il quale l’interprete deve accedere al servizio solo tramite richieste HTTPS. 

Ciò significa che la prima volta che si accede a un sito tramite HTTPS restituisce l’intestazione Strict-Transport-Security, il browser registra queste informazioni, quindi i tentativi futuri di caricare il sito tramite HTTP utilizzano automaticamente HTTPS.

Allo scadere del tempo di scadenza specificato dall’intestazione Strict-Transport-Security, il prossimo tentativo di caricare il sito tramite HTTP procederà normalmente invece di utilizzare automaticamente HTTPS.

Tuttavia, ogni volta che l’intestazione Strict-Transport-Security viene consegnata all’agente utente, aggiornerà il tempo di scadenza per quel sito, in modo che i siti possano aggiornare queste informazioni e impedire la scadenza del timeout.

Qualora fosse necessario disabilitare HSTS, i server web possono impostare la massima età a 0 (su una connessione HTTPS) per far scadere immediatamente l’intestazione HSTS, consentendo l’accesso tramite richieste HTTP.

Ad esempio, un server potrebbe inviare un’intestazione che richiede che le richieste future per il prossimo anno utilizzino solo HTTPS tramite Strict-Transport-Security: max-age=31536000

Quando un’applicazione Web invia una politica HSTS agli agenti utente, gli agenti utente conformi si comportano come segue:

  • Eventuali collegamenti non sicuri vengono automaticamente trasformati in collegamenti sicuri (ad es. http://example.com/ verrà modificato in https://example.com prima di accedere al server)
  • Se non è possibile garantire una connessione sicura (ad es. il server non dispone di un certificato valido), lo user agent interromperà la connessione e non consentirà all’utente di accedere al sito web.

La cosa più importante da capire è che una politica HSTS impedisce l’insicurezza del click-through non consentendo all’utente finale di utilizzare la connessione non sicura.

Qual è un esempio di situazione che coinvolge HSTS?

Immagina che il tuo membro del personale utilizzi un punto di accesso Wi-Fi gratuito in un bar e inizi a navigare sul Web, visitando il sistema di buste paga della tua organizzazione.

Sfortunatamente, il punto di accesso che stanno utilizzando è in realtà il laptop di un utente malintenzionato e stanno intercettando la richiesta HTTP originale e reindirizzando il tuo dipendente a un clone del tuo sistema di gestione stipendi anziché a quello reale, esponendo le  informazioni di identificazione personale (PII) dei tuoi dipendenti .

Se il tuo sistema di gestione stipendi utilizza HSTS e il tuo dipendente lo ha visitato una volta utilizzando HTTPS, il suo browser saprà di utilizzare solo HTTPS, impedendo questo tipo di  attacco man-in-the-middle .

Quali sono i limiti dell’HSTS?

Una limitazione fondamentale dell’utilizzo di HSTS è che un utente che non può connettersi tramite HTTPS non sarà in grado di utilizzare il sito.

Inoltre, poiché la politica HSTS viene comunicata in un’intestazione di risposta, richiede che l’agente utente visiti prima il sito Web per apprendere che utilizza HSTS.

Ciò significa che la richiesta iniziale rimane non protetta da attacchi attivi se utilizza un protocollo non sicuro come HTTP semplice o se l’URI per la richiesta iniziale è stato ottenuto su un canale non sicuro.

Ciò si applicherà anche alla prima richiesta dopo il periodo di attività specificato nell’HSTS max-age (i siti generalmente impostano un periodo di diversi giorni o mesi a seconda dell’attività e del comportamento dell’utente).

Esiste un supporto browser diffuso per HSTS, inclusi Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera e Safari, per risolvere questa limitazione precaricando i criteri HSTS dall’elenco di precaricamento HSTS. L’elenco HSTS contiene siti Web noti che supportano HSTS e sono distribuiti con il browser, quindi utilizza HTTPS per la richiesta iniziale per i siti Web elencati. 

Poiché questo approccio non può mai scalare sull’intero Web, ci sono state discussioni per poter dichiarare HSTS nei record DNS e accedervi in modo sicuro tramite  DNSSEC , che potrebbe garantire la validità.

Inoltre, HSTS è inefficace contro  domini di typosquatting , attacchi basati su DNS e attacchi man-in-the-middle che servono il traffico da un dominio artificiale che non è nell’elenco di precaricamento HSTS.

E poiché HSTS si basa su TLS stesso, si basa anche sulla sicurezza di TLS.

Leggere  RFC 6797  per una discussione più approfondita delle considerazioni generali sulla sicurezza HSTS.

Quali sono le best practice per la distribuzione di HSTS?

Se il tuo sito è vincolato a HTTPS e desideri precaricare HSTS, devi:

  • Fornire un certificato valido
  • Reindirizza da HTTP a HTTPS sullo stesso host, se sei in ascolto sulla porta 80
  • Servi tutti i sottodomini su HTTPS
  • Devi supportare HTTPS per il sottodominio www se esiste un record DNS per quel sottodominio
  • Serve can HSTS header nel dominio di base per le richieste HTTPS:
  • L’età massima deve essere di almeno 31536000 secondi (1 anno) deve essere almeno
  • È necessario specificare la direttiva includeSubDomains
  • La direttiva di precarico deve essere specificata
  • Se stai servendo un reindirizzamento aggiuntivo dal tuo sito HTTPS, quel reindirizzamento deve ancora avere l’intestazione HSTS (piuttosto che la pagina Web a cui reindirizza)

Ti consigliamo di iniziare con i seguenti passaggi:

  • Esamina tutti i sottodomini e i sottodomini nidificati del tuo sito e assicurati che funzionino su HTTPS.
  • Abilita HSTS per tutte le risposte HTTPS e aumenta gradualmente l’età massima. Durante ogni fase, controlla la presenza di pagine rotte, monitora le metriche del tuo sito e risolvi eventuali problemi che si verificano, quindi attendi l’età massima della fase prima di andare avanti. È possibile utilizzare i seguenti valori di intestazione:
  • 5 minuti – Sicurezza dei trasporti rigorosi: max-età=300; includeSubDomains
  • 1 settimana – Sicurezza dei trasporti rigorosi: età-max=604800; includeSubDomains
  • 1 mese – Strict-Transport-Security: max-age=2592000; includeSubDomains
  • 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:
  • 2 anni – Sicurezza dei trasporti rigorosi: età-max=63072000; includeSubDomains; precarico
  • Puoi aggiungere il tuo sito Web all’elenco di precaricamento HSTS tramite  https://hstspreload.org/ .

Questo è ciò che i progetti Chromium vogliono vedere in un invio di precaricamento.

Qual è la storia dell’HSTS?

La specifica HSTS (RFC 6797) si basa sul lavoro originale di Collin Jackson e Adam Barth in un documento intitolato  ForcedHTTPS: Protecting High-Security Web Sites from Network Attacks  , pubblicato nel 2008.

Il 18 settembre 2009, PayPal, Jackon e Barth hanno pubblicato una versione aggiornata dello schema del protocollo nel documento originale,  disponibile qui .

Ciò ha portato all’ultima “versione comunitaria” della specifica “STS” allora denominata pubblicata il 18 dicembre 2009, con revisioni basate sul feedback della comunità.

Infine, il 19 novembre 2012 è stata pubblicata la specifica HSTS (RFC 6797) dopo essere stata approvata il 2 ottobre 2012  dall’Internet Engineering Steering Group (IESG) , organismo composto  dal  presidente  della Internet Engineering Task Force (IETF) e dai direttori di area.

Quali browser supportano HSTS?

  • Chromium e Google Chrome dalla versione 4.0.211.0
  • Firefox dalla versione 4; con Firefox 17, Mozilla integra un elenco di siti Web che supportano HSTS
  • Opera dalla versione 12
  • Safari da OS X Mavericks versione 10.9
  • Internet Explorer 11 su Windows 8.1 e Windows 7 quando è installato KB 3058515
  • Microsoft Edge e Internet Explorer 11 su Windows 10
  • BlackBerry 10 Browser e WebView da BlackBerry OS 10.3.3

Hai dei dubbi? Non sai da dove partire? Contattaci


Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

ManagedServer.it è il principale provider italiano di soluzioni hosting ad alte performance. Il nostro modello di sottoscrizione ha costi contenuti e prevedibili, affinché i clienti possano accedere alle nostre affidabili tecnologie di hosting, server dedicati e cloud. ManagedServer.it offre, inoltre, eccellenti servizi di supporto e consulenza su Hosting dei principali CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Magento.

Torna su