Guía para los implementadores de sitios que solo utilizan HTTPS (lado del servidor)

Los principales son:

• Use SSL en todo el sitio. No ofrezca nada a través de http. En su lugar, cualquier conexión a través de http debe redirigirse inmediatamente a la página de destino del sitio principal a través de https.

• Use HTTPS Strict Transport Security. Esto le dirá a los navegadores de los usuarios: por favor, solo conéctese a través de https. Esto se defiende contra sslstrip y ataques similares de intermediarios.

• Establezca la marca de seguridad en todas las cookies. Esto asegurará que las cookies solo se enviarán a través de un canal https, nunca a través de un enlace http inseguro.

• Evite el contenido activo de terceros servido a través de http. No cargue contenido activo externo a través de http. Asegúrese de que cualquier CSS, Javascript, widgets, análisis o anuncios que cargue de fuentes de terceros se carguen a través de https.

  • Potencialmente mejor aún, puede considerar hacer su propia copia y servir estos recursos desde su propio servidor, si es posible, por lo que no necesita cargarlos desde una fuente de terceros. En muchos casos, puede evitar cargar CSS, bibliotecas de Javascript o widgets de fuentes de terceros simplemente almacenando una copia en su propio servidor.

  • Para análisis, tenga en cuenta que Google Analytics admite https.

  • Los anuncios son la parte más difícil. Si usa anuncios, es posible que no tenga más remedio que aceptar anuncios de terceros a través de http, lo que es un riesgo de seguridad. Si lo hace, sirva los anuncios en un iframe (no use SCRIPT SRC para integrar los anuncios en su página).

  Está bien cargar imágenes alojadas en un host de terceros siempre que se carguen a través de HTTPS (para evitar advertencias de contenido mixto).

Creo que si haces estas cuatro cosas, cubrirás la mayoría de los problemas. El resto son detalles que se pueden evaluar en función del sitio, pero probablemente tengan una importancia secundaria (en mi opinión).

Si desea obtener un diseño elegante, puede ver la fijación de certificados y tecnologías emergentes similares, pero a partir de los cuatro anteriores ya es un proyecto suficientemente significativo.

Seguridad del usuario

• Te estás perdiendo una cosa extremadamente importante : la mitigación CSRF.

  Asegúrese de comprenda completamente los problemas relacionados. Tldr: en además del token de autorización (por ejemplo, cookie de sesión), necesita una acción de desafío por para identificar si la acción es realizada por el usuario o no intencionada.

• Arregle Fugas en JSONP .

• X-Content-Type-Options: nosniff , en todas las páginas para evitar que MIME detecte especialmente para páginas generadas por el usuario.

• Política de seguridad del contenido .

• Asegúrese de que el mecanismo de "restablecer contraseña" sea seguro para evitar que las personas reinicien la contraseña de otras personas y se vuelvan fraudulentas. acceso.

• Muestra una advertencia enorme enorme cuando los usuarios usan contraseñas débiles o no la aceptan del todo.

• Capacite a los usuarios (tal vez a través de una imagen de flecha en cada página que apunta a la barra verde) para verificar si sus páginas están cargadas con HTTPS. Si alguna vez usan un navegador que no es compatible con HSTS, al menos notarán que falta HTTPS.

Seguridad del servidor / usuario

• Asegúrese de que los secretos no se filtren debido a sincronización attacks .

Privacidad del usuario

• No es suficiente aplicar el relleno a ajax. Para proteger a sus usuarios contra el monitoreo de la red , todas las solicitudes y respuestas deben ser datos acolchado. No es necesario que las solicitudes se rellenen con el tiempo, pero las respuestas deben hacerlo.

• Solucione la filtración en el historial debido a la varianza en los tiempos para las respuestas :

    

  Supongamos que Alice navega por la web y visita la web de Bob   sitio en http://www.bob.com . Bob quiere saber si   Alice ha visitado el sitio web de Charlie ( http://www.charlie. com ).

       

  Primero, Bob mira el sitio de Charlie y selecciona un archivo que cualquier visitante   Al sitio habremos visto. Digamos que Bob escoge el archivo que contiene   Logotipo corporativo de Charlie, en http://www.charlie.com/   logo.jpg. Bob va a determinar si el archivo del logo está en   El caché web de Alice. Si el archivo está en su caché, entonces ella debe tener   Visité el sitio web de Charlie recientemente.

       

  Bob escribe un applet de Java que implementa su ataque e inserta   En su página de inicio. Cuando Alice ve la página de ataque, el   El applet de Java se descarga automáticamente y se ejecuta en el navegador de Alice.   El applet mide el tiempo requerido para acceder a http://www. charlie.com/logo.jpg en la máquina de Alice, e informa de esto   tiempo de regreso a Bob. Si el tiempo es inferior a algún umbral (por ejemplo, 80   milisegundos), Bob concluye que Alice ha estado en el sitio de Charlie   recientemente; si es mayor que el umbral, concluye que ella tiene   No he estado en el sitio recientemente.

Privacidad del servidor

• Garantice la invulnerabilidad de los ataques de sesgo de reloj .

Disponibilidad

• Limitación basada en el usuario / basada en IP en el caso de DoS y DDoS .

Otras cosas misceláneas que no puedes arreglar (problemas con el navegador):

• Fuga en la historia a través de HSTS