Riesgos de degradación de HTTP y contenido mixto

El encabezado HTTP Strict Transport Security (HSTS) indica a los navegadores que se conecten a un sitio únicamente mediante HTTPS durante un periodo determinado. Una vez recibido, el navegador rechaza las conexiones HTTP y actualiza automáticamente las URL http:// a https://.

Un encabezado HSTS habitual: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". El valor max-age se expresa en segundos (31536000 = 1 año). Una vez almacenado en la caché, el navegador impone el uso de HTTPS durante un año sin intervención del servidor.

El parámetro max-age establece durante cuánto tiempo el navegador debe imponer conexiones exclusivamente mediante HTTPS, en segundos. Para los sitios en producción, se recomiendan valores de al menos un año (31536000).

La directiva includeSubDomains extiende la aplicación de HSTS a todos los subdominios. Esto impide ataques en los que un atacante degrada la conexión de un subdominio a HTTP y la utiliza para robar cookies establecidas sin la marca Secure en el dominio principal.

Los navegadores incluyen una lista codificada de dominios que siempre requieren HTTPS, incluso durante la primera visita. Esta lista, mantenida en hstspreload.org, incluye miles de sitios web importantes.

La precarga elimina la vulnerabilidad de la primera visita: sin ella, un visitante nuevo podría ser interceptado antes de recibir el encabezado HSTS. Los sitios precargados solo utilizan HTTPS desde la primera solicitud, independientemente del estado de la caché de HSTS.

El SSL stripping, presentado por Moxie Marlinspike en Black Hat 2009, es un ataque MITM que degrada las conexiones HTTPS a HTTP. El atacante intercepta la solicitud HTTP inicial del usuario, realiza solicitudes HTTPS al servidor real en nombre del usuario y reenvía el contenido al usuario mediante HTTP.

La víctima ve el contenido con normalidad, pero a través de HTTP. Las credenciales que introduzca se envían al atacante. Antes de HSTS, este ataque era muy eficaz porque los usuarios no advertían la ausencia del candado.

HSTS impide el SSL stripping porque el navegador rechaza las conexiones HTTP a dominios incluidos en HSTS. Aunque un atacante intente servir una página mediante HTTP, el navegador simplemente se niega a conectarse y muestra un error.

La aplicación de HSTS por parte del navegador ocurre antes de cualquier solicitud de red, por lo que el atacante no puede interferir. La única vulnerabilidad restante es la primera visita, antes de recibir HSTS; la precarga la elimina.

El contenido mixto aparece cuando una página HTTPS carga recursos mediante HTTP. El contenido mixto pasivo incluye imágenes, audio y vídeo cargados mediante HTTP. Estos recursos no pueden modificar directamente la página, pero pueden revelar información del usuario a través de encabezados HTTP y permitir el rastreo.

El contenido mixto activo incluye scripts, hojas de estilo, iframes y XMLHttpRequests cargados mediante HTTP. Un script HTTP puede comprometer por completo la seguridad de la página HTTPS, ya que tiene acceso total al DOM y puede leer cookies y datos de formularios.

Los navegadores modernos bloquean de forma predeterminada el contenido mixto activo (scripts, hojas de estilo e iframes mediante HTTP) cuando la página contenedora utiliza HTTPS. Se muestra un error en la consola y el recurso no se carga.

A partir de Chrome 81 (2020), los navegadores comenzaron a actualizar automáticamente a HTTPS el contenido mixto pasivo. Si existe la versión HTTPS, se carga. Si no existe, el recurso se bloquea.

La consola de desarrollo del navegador muestra advertencias y errores de contenido mixto. En Chrome, abra DevTools, vaya a la pestaña Console y filtre por "Mixed Content". Cada recurso bloqueado muestra la URL no segura que debe actualizarse.

El panel Security de DevTools muestra un resumen completo de la seguridad: detalles del certificado, información de la conexión y una lista de todos los recursos no seguros de la página.

La directiva de Content Security Policy (CSP) "upgrade-insecure-requests" indica a los navegadores que actualicen automáticamente a HTTPS todas las solicitudes HTTP de la página. Esto permite gestionar contenido heredado con URL HTTP codificadas de forma fija.

A diferencia del bloqueo del contenido mixto, upgrade-insecure-requests intenta obtener primero la versión HTTPS. Resulta útil durante la migración de HTTP a HTTPS, cuando actualizar todas las URL incrustadas en contenido heredado no resulta práctico.

Sin HTTPS, los ISP pueden inyectar contenido en las respuestas HTTP. Se ha descubierto que varios ISP inyectaban anuncios en páginas web que no los incluían, añadían píxeles de seguimiento o insertaban páginas de advertencia cuando los usuarios se acercaban a su límite de datos.

Esta forma de inyección de contenido es imposible en páginas HTTPS porque la respuesta está autenticada y cifrada. Cualquier modificación haría fallar la verificación del MAC de TLS, lo que produciría un error de conexión en lugar de servir contenido modificado.

Antes de que un navegador haya recibido un encabezado HSTS para un dominio, la primera visita mediante HTTP es vulnerable. Un atacante puede interceptar esta solicitud inicial y realizar un SSL stripping sin provocar ninguna advertencia del navegador.

Esta vulnerabilidad de «confianza en el primer uso» explica la existencia de la lista de precarga de HSTS. Enviar un sitio a la lista de precarga garantiza que los navegadores impongan HTTPS para ese dominio desde la primera solicitud, cerrando por completo la ventana de vulnerabilidad de la primera visita.

Compruebe sus conocimientos sobre HTTP Strict Transport Security.

HSTS indica a los navegadores que impongan conexiones exclusivamente mediante HTTPS para un dominio durante un periodo determinado. La lista de precarga extiende la protección a las primeras visitas al incluir las políticas HSTS de forma codificada en los navegadores.

El SSL stripping (Moxie Marlinspike, 2009) degrada HTTPS a HTTP; HSTS lo impide. Los navegadores bloquean el contenido mixto activo (scripts HTTP en páginas HTTPS). La directiva CSP upgrade-insecure-requests automatiza la migración de HTTP a HTTPS para contenido heredado.