Respuesta HTTP de Twitter vs Respuesta HTTP de Google

15

Estaba viendo las respuestas HTTP de enlace y enlace . Estas dos respuestas tienen similitudes y diferencias interesantes en sus definiciones de seguridad.

Tanto Twitter como Google tienen estos elementos de encabezado en común por motivos de seguridad:

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

Sin embargo, twitter tiene una declaración cache-control más extensa y utiliza HSTS:

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

Preguntas :

  1. ¿Hay alguna razón para no usar HSTS? ¿Google depende de Precarga de HSTS , y la aplicación web "normal" debería habilitar HSTS?
  2. ¿Los usuarios de Google son más susceptibles a la información relacionada con el caché? revelación que los usuarios de Twitter debido a la diferente definición de cache-control ?

Para estar completo, he incluido el encabezado HTTP completo para ambos sitios.

La respuesta HTTP de enlace :

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 respuesta HTTP de enlace :

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
    
pregunta rook 06.10.2013 - 21:54
fuente

2 respuestas

9

Google no está utilizando la aplicación de HSTS. Ni en precarga ni en cabeceras. La entrada HSTS precargada en Chrome se establece en "OPPORTUNISTIC", que básicamente significa "no aplicado", aunque contiene un conjunto de hashes de certificados permitidos para evitar MITM.

La redirección de Google a https depende de los criterios de detección del navegador, como el agente de usuario. No sé exactamente qué criterios verifican, pero, por ejemplo, navegar por google.com utilizando Links no redirigir a https, y la búsqueda en canales no cifrados todavía está permitida, aunque la navegación desde Chrome redirigirá (con un 302) a https. Además, muchas URL en el dominio no se redirigen a https sin importar qué navegador utilice. Por ejemplo: enlace

Su razón para no requerir SSL no está documentada explícitamente en ninguna parte, pero probablemente tenga que ver con el hecho de que hacerlo podría "romper las cosas", aunque es probable que estén mal escritas. La trayectoria actual parece apuntar hacia la migración de todo Google a SSL, pero lo están haciendo una pieza a la vez. Mi mejor estimación sería esperar que el HSTS se cumpla dentro de 5 años.

La diferencia de control de caché refleja el hecho de que la página principal de Google es estática, mientras que la de Twitter se actualiza constantemente con nuevos tweets. Google permite que el navegador guarde (en privado) la página de inicio del cuadro de búsqueda por un tiempo limitado, pero Twitter requiere una recarga para obtener el último lote de información filosófica profunda de todos tus amigos de Twitter.

En cuanto a las revelaciones de información relacionada con el caché; No estoy al tanto de ninguna. La página de inicio de Google no contiene información personal a menos que se entregue a través de HTTPS (en cuyo caso aparece esa barra en la parte superior), lo que limita el potencial de divulgación.

    
respondido por el tylerl 08.10.2013 - 23:26
fuente
3

Que yo sepa, no hay razón para no usar HSTS si su sitio ya aplica TLS por otros medios. Los agentes de usuario que no cumplen las normas simplemente ignorarán el encabezado, por lo que no hay problema allí. ¿Reduciría HSTS la carga en el host? Ya no necesita seguir sirviendo las redirecciones, ya que los agentes de usuario compatibles navegan directamente a la https: // URI. La precarga de HSTS cubre a muchos usuarios, pero no todos como usted afirma, es un poco extraño que no emitan la Política de HSTS.

En cuanto al número 2 no estoy seguro lo siento.

    
respondido por el Scott Helme 08.10.2013 - 10:04
fuente

Lea otras preguntas en las etiquetas