HTTP Strict Transport Security: differenze tra le versioni

Versione delle 16:43, 18 ott 2016

Versione delle 02:29, 16 gen 2017

Riga 7:

== 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"><cite class="citation web" contenteditable="false">Hodges, Jeff; Steinguebl, Andy (29 October 2010). </cite></ref>

Riga 22 ⟶ 21:

== Panoramica della procedura ==

Un server implementa la politica HSTS se emette la relativa intestazione in un messaggio di una comunicazione HTTPS (su HTTP tali intestazioni sono invece ignorate).<ref><cite class="citation web" contenteditable="false">[https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security "HTTP Strict Transport Security"].</cite></ref>

Per esempio, un server potrebbe inviare un'intestazione che richieda che ogni richiesta a lui diretta nell'anno successivo sia trasmessa necessariamente tramite HTTPS.

Riga 34 ⟶ 32:

== Applicabilità ==

La vulnerabilità di sicurezza più importante che possa essere scongiurata da HSTS è il cosiddetto [[Attacco man in the middle|man-in-the-middle]] con la tecnica di ''SSL-stripping'', illustrata pubblicamente per la prima volta nel 2009 da Moxie Marlinspike nel suo intervento «''New Tricks For Defeating SSL In Practice»'' (Messa in pratica dei nuovi trucchi per sconfiggere SSL) presentato al ''BlackHat Federal''.<ref>{{Cita pubblicazione|url= https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf|titolo= New Tricks For Defeating SSL In Practice}}</ref><ref>[https://www.youtube.com/watch?v=MFol6IMbZ7Y Defeating SSL Using Sslstrip]<span contenteditable="false"> on </span>[[YouTube]]</ref>

Questo attacco consiste nel convertire silenziosamente una connessione HTTP sicura, appoggiata a [[Transport Layer Security|SSL]] o a [[Transport Layer Security|TLS]], in una connessione HTTP in chiaro: l'utente può verificare che effettivamente la connessione non sia sicura, ma non ha alcun modo di sapere che essa debba esserlo.

Riga 49 ⟶ 46:

== Limiti ==

Di fronte ad attacchi attivi, la presenza di HSTS non è in grado di proteggere la prima richiesta ad un'applicazione web, quando quella sia veicolata su un protocollo non sicuro come HTTP in chiaro o quando il relativo [[Uniform Resource Identifier|URI]] è stato ottenuto su un canale insicuro.<ref name="hsts-bootstrap-mitm">{{Cita web|url= https://tools.ietf.org/html/rfc6797#section-14.6|titolo= Section 14.6. Bootstrap MITM Vulnerability|sito= RFC 6797|editore= IETF|cognome= Hodges|nome= Jeff|autore2= Jackson, Collin|autore3= Barth, Adam|data= November 2012|accesso= 21 novembre 2012}}</ref>

Lo stesso vale per la prima richiesta che sia effettuata dopo la scadenza del periodo precisato dal parametro <code><nowiki>max-age</nowiki></code> annunciato nella politica HSTS.

Riga 72 ⟶ 68:

== Buone norme per la messa in opera ==

A seconda della specifica messa in opera, certe buone norme consentono di evitare alcune minacce alla sicurezza, come gli attacchi con iniezione di cookie.

* Gli host HSTS dovrebbero dichiarare la politica HSTS nel loro nome di livello massimo: per esempio, un server in ascolto su <nowiki>https://sub.example.com</nowiki> dovrebbe rispondere con l'intestazione HSTS anche per richieste a <nowiki>https://example.com .</nowiki>

Riga 78 ⟶ 73:

== Note ==

<references/>

== Voci correlate ==

* [[HTTPS]]

== Collegamenti esterni ==

* {{en}} [[rfc:6797|RFC 6797, HTTP Strict Transport Security (HSTS)]]

* {{cita web|https://tools.ietf.org/wg/websec/charters|IETF WebSec Working Group|lingua=en}}

Riga 96 ⟶ 88:

{{Portale|informatica|sicurezza informatica|telematica}}

[[Hypertext Transfer Protocol]]

[[Categoria:Sicurezza informatica]]

[[Categoria:Crittografia]]

[[Categoria:HTTP]]

[[Categoria:Protocolli di Internet]]