Risposta HTTP di Twitter rispetto alla risposta HTTP di Google

15

Stavo osservando il modulo link e link . Queste due risposte hanno interessanti somiglianze e differenze nelle loro definizioni di sicurezza.

Sia Twitter che Google hanno in comune questi elementi di intestazione ai fini della sicurezza:

X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Server: *custom*
Expires: *in the past*
Cache-Control: private***

Tuttavia, Twitter ha una dichiarazione cache-control più estesa e utilizza HSTS:

cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
strict-transport-security: max-age=631138519

Domande:

  1. C'è qualche ragione per non usare l'HSTS? Google dipende da precarica HSTS e l'applicazione web "normale" dovrebbe abilitare HSTS?
  2. Gli utenti di Google sono più sensibili alle informazioni relative alla cache divulgazione rispetto agli utenti di Twitter a causa della diversa cache-control definizione?

Per completezza ho incluso l'intestazione HTTP completa per entrambi i siti.

La risposta HTTP dal link :

HTTP/1.1 200 OK
Date: Sun, 06 Oct 2013 19:27:33 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=REMOVED
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 443:quic
Content-Length: 100392

La risposta HTTP dal link :

HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Length: 50221
content-type: text/html;charset=utf-8
date: Sun, 06 Oct 2013 19:33:08 GMT
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Sun, 06 Oct 2013 19:33:08 GMT
ms: S
pragma: no-cache
server: tfe
set-cookie: _twitter_sess=REMOVED
status: 200 OK
strict-transport-security: max-age=631138519
x-frame-options: SAMEORIGIN
x-transaction: 699d2669d76b27f5
x-ua-compatible: IE=10,chrome=1
x-xss-protection: 1; mode=block
    
posta rook 06.10.2013 - 21:54
fonte

2 risposte

9

Google non sta utilizzando l'applicazione HSTS. Né nel precaricamento né nelle intestazioni. La voce HSTS precaricata in Chrome è impostata su "OPPORTUNISTIC", che in pratica significa "non forzato", sebbene contenga un set di hash certificati per impedire MITM.

Il reindirizzamento di Google a https dipende dai criteri di rilevamento del browser, come user-agent. Non so con precisione quali criteri controllano, ma per esempio sfogliare google.com utilizzando Collegamenti non reindirizzare a https e la ricerca su canali non criptati è ancora consentita, anche se la navigazione da Chrome reindirizzerà (con un 302) a https. Inoltre, molti URL sul dominio non vengono reindirizzati a https, indipendentemente dal browser utilizzato. Ad esempio: link

La loro ragione per non richiedere SSL non è esplicitamente documentata da nessuna parte, ma probabilmente ha a che fare con il fatto che fare ciò potrebbe "rompere le cose" - anche se le cose scritte male, molto probabilmente. L'attuale traiettoria sembra puntare a migrare tutto di Google su SSL, ma lo fanno un pezzo alla volta. La mia ipotesi migliore sarebbe quella di prevedere l'applicazione dell'HSTS entro 5 anni.

La differenza di controllo della cache riflette il fatto che la home page di Google è statica, mentre Twitter è costantemente aggiornata con nuovi tweet. Google consente al browser di memorizzare (in privato) la pagina iniziale della casella di ricerca per un periodo di tempo limitato, ma Twitter richiede una ricarica per recuperare l'ultima serie di profonde intuizioni filosofiche da tutti i tuoi amici di Twitter.

Per quanto riguarda le informazioni sulle informazioni relative alla cache; Non ne sono a conoscenza. La home page di Google non contiene informazioni personali se non viene fornita tramite HTTPS (nel qual caso la barra viene visualizzata in alto), il che limita il potenziale di divulgazione.

    
risposta data 08.10.2013 - 23:26
fonte
3

Per quanto ne so, non vi è alcun motivo per non utilizzare HSTS se il tuo sito applica già TLS con altri mezzi. Agenti utente non conformi ignorano semplicemente l'intestazione, quindi non vi è alcun problema. HSTS avrebbe ridotto il carico sull'host? Non è più necessario continuare a servire i reindirizzamenti poiché gli user agent conformi navigano direttamente all'URL https: //. Il pre-caricamento di HSTS copre molti utenti ma non tutti come dichiari, è un po 'strano che non pubblichino la politica HSTS.

Per quanto riguarda il numero 2, non sono sicuro.

    
risposta data 08.10.2013 - 10:04
fonte

Leggi altre domande sui tag