HTTP Strict Transport Security: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
m rb - meglio prima Etichetta: Ripristino manuale |
||
Riga 1:
'''''HTTP Strict Transport Security''''' o '''''HSTS''''' (in italiano '''sicurezza rigida per il trasporto di HTTP''') è una procedura che implementa una politica di sicurezza per le comunicazioni [[web]], necessaria a proteggere il canale [[HTTPS]] da attacchi di [[degrado della sicurezza]] (''downgrade'') e assai utile per la protezione dai [[Dirottamento di sessione|dirottamenti di sessione]].
HSTS permette al [[server web]] di dichiarare che i [[browser]] e ogni altro tipo di [[client]] debbano comunicare con esso esclusivamente attraverso connessioni sicure su [[Protocollo di rete|protocollo]] HTTPS e non sul semplice [[HTTP]]<ref name="https">HTTPS denota HTTP sopra lo strato [[Transport Layer Security|TLS/SSL]].</ref>.
La procedura è uno standard di Internet della [[IETF]], normato dal [[Request for Comments|RFC]] 6797.
La politica HSTS<ref name="hsts-no-user-recourse">Hodges, Jeff; Jackson, Collin; Barth, Adam (novembre 2012).</ref> è indicata dal server allo [[user agent]] specificando una particolare intestazione nei messaggi di risposta [[Hypertext Transfer Protocol|HTTP]], denominata «<code>Strict-Transport-Security</code>» che specifica il periodo di tempo durante il quale il client dovrà accedere al server in modalità necessariamente sicura. == Storia della specifica ==
HSTS è la concretizzazione di uno degli aspetti della visione progettuale di Jeff Hodges e Andy Steingruebl per migliorare la sicurezza del web, e presentata nel 2010 all'interno del loro articolo 2010 intitolato ''The Need for Coherent Web Security Policy Framework(s)''.<ref name="web-sec-policy-frmwk">Hodges, Jeff; Steinguebl, Andy (29 ottobre 2010).
Le specifiche HSTS si basano sul contributo originale di Jackson e Barth descritto nell'articolo ''ForceHTTPS: Protecting High-Security Web Sites from Network Attacks''.<ref name="forcehttps-paper">{{Cita web |url=https://crypto.stanford.edu/forcehttps/|titolo="ForceHTTPS: Protecting High-Security Web Site from Network Attacks"}}</ref>
La prima bozza originale delle specifiche fu scritta da Jeff Hodges<ref name="jeffhodges-ext">{{Cita web |url=http://kingsmountain.com/people/Jeff.Hodges/|titolo="Jeff Hodges's homepage"}}</ref> di [[PayPal]], Collin Jackson<ref name="collinjackson-ext">{{Cita web |url=http://www.collinjackson.com/|titolo="Collin Jackson's homepage"}}</ref> e Adam Barth<ref name="adambarth-ext">{{Cita web |url=http://www.adambarth.com/|titolo="Adam Barth's homepage"}}</ref> e pubblicata 18 settembre 2009.<ref name="draft-spec">{{Cita web |url=https://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html |titolo="Strict Transport Security -05" |data= 18 settembre 2009}}</ref> La prima specifica di HSTS fu resa pubblica il 18 dicembre 2009 e corrispose all'ultima cosiddetta "versione della comunità", che beneficiava appunto del riscontro pubblico.<ref name="STS-draft-spec-2">{{Cita web |url=https://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html |titolo= "Strict Transport Security -06" |data= 18 dicembre 2009}}</ref> In seguito all'approvazione del 2 ottobre 2012 da parte dell'[[Internet Engineering Steering Group|IESG]], la specifica di HSTS è stata pubblicata come [[Request for Comments|RFC]] ''Proposed Standard'' (standard proposto) il 19 novembre 2012 nel RFC 6797<ref name="hsts-ps-rfc-approval-iesg-msg">{{Cita web |url=https://www.ietf.org/mail-archive/web/websec/current/msg01401.html|titolo="[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)"|data=2 ottobre 2012}}</ref>.
Riga 29 ⟶ 35:
Inoltre il processo di regressione di sicurezza non genera alcun messaggio d'avvertimento all'utente, rendendo l'attacco discreto agli occhi di quasi chiunque. Lo strumento sslstrip di Marlinspike automatizza completamente tale attacco.
HSTS si occupa di questo problema<ref name="hsts-threats-addressed"/> informando il browser che le sue connessioni al sito dovrebbero fare sempre uso di TLS/SSL.
Visto che l'intestazione HSTS può però essere comunque manomessa da un attaccante nel momento della prima visita da parte di un utente, [[Google Chrome]], [[Mozilla Firefox]], [[Internet Explorer]] e [[Microsoft Edge]] cercano di limitare la problematica inserendo un elenco preliminare dei siti HSTS.<ref name="preloading_hsts_chromium">{{Cita web|url= https://www.chromium.org/sts|autore= Adam Langley|titolo= Strict Transport Security|sito= The Chromium Projects|data= 8 luglio 2010|accesso= 22 luglio 2010}}</ref><ref name="preloading_hsts_mozilla">David Keeler (1 novembre 2012).</ref><ref name="iepreload">{{Cita web|url= https://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx|titolo= HTTP Strict Transport Security comes to Internet Explorer|accesso= 16 febbraio 2015|autore= Mike Bell|autore2= David Walp|data= 16 febbraio 2015}}</ref> Nel prossimo paragrafo [[Strict Transport Security|Limiti]] si discuterà anche di come questa soluzione sia necessariamente insufficiente, dato che il suddetto elenco non può essere esaustivo.
HSTS aiuta anche a evitare il furto di credenziali di accesso a siti web basati su [[Cookie|cookie HTTP]], un attacco praticabile con strumenti facilmente disponibili, quale [[Firesheep]].<ref>{{Cita web|url= http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/|autore= Jeff Hodges|titolo= Firesheep and HSTS (HTTP Strict Transport Security)|data= 31 ottobre 2010|accesso= 8 marzo 2011}}</ref> Dato che HSTS ha limiti temporali, il protocollo è sensibile ad attacchi che prevedono di spostare l'orologio della vittima, per esempio inviando falsi pacchetti [[Network Time Protocol|NTP]].<ref>{{Cita web|url= https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf|titolo= Bypassing HTTP Strict Transport Security|data= 17 ottobre 2014|accesso= 22 ottobre 2014|autore= Jose Selvi}}</ref>
| |||