Imagínate que estás en tu restaurante favorito o que simplemente regresas a tu habitación de hotel desde esa conferencia y deseas utilizar la conexión Wi-Fi gratuita. ¿Alguna vez has notado que las contraseñas de Wi-Fi están impresas en papel y nunca cambian?
Un hacker malévolo ha reservado una habitación en este mismo hotel. Están escuchando a escondidas todas las conexiones que pasan por esta red inalámbrica insegura.
El hacker tiene algo llamado ‘sniffer de paquetes’. Un sniffer de paquetes es una utilidad de red que analiza y puede inyectar tareas en el flujo de datos que viaja a través de la red objetivo.
Este hacker podría capturar el tráfico de tu red a través de HTTP para cualquier sitio web que se base solo en redirecciones 301 para cambiar de HTTP a HTTPS. Este método presenta una oportunidad para que el pirata informático elimine tu encriptación SSL y robe datos valiosos o, lo que es peor, presente una página de portal de inicio de sesión falsa.
Es por eso que tu sitio web debe emplear HTTP Strict Transport Security en lugar de solo HTTPS. Obtener un certificado SSL nunca será suficiente.
Veamos qué es HSTS (HTTP Strict Transport Security), cómo funciona y cómo implementarlo.
Indice
¿Qué es HSTS (HTTP Strict Transport Security)?
HTTP Strict Transport Security (HSTS) es un mecanismo de política de seguridad web que permite a los sitios web declararse accesibles solo a través de conexiones seguras. Esto ayuda a proteger los sitios web y los usuarios de la degradación del protocolo y los ataques de secuestro de cookies.
Es un método utilizado por los sitios web para declarar que solo se debe acceder a ellos mediante una conexión segura (HTTPS). Si un sitio web declara una política HSTS, el navegador debe rechazar todas las conexiones HTTP y evitar que los usuarios acepten certificados SSL inseguros.
Actualmente, HSTS es compatible con la mayoría de los principales navegadores.
HTTP Strict Transport Security se definió como un estándar de seguridad web en 2012 en RFC 6797. El objetivo principal de crear este estándar era ayudar a evitar ataques de hombre en el medio (MITM) que usan stripping SSL.
Historia
La especificación HSTS (RFC 6797) se basa en el trabajo original de Collin Jackson y Adam Barth en un documento llamado ForcedHTTPS: Protección de sitios web de alta seguridad contra ataques de red que se publicó en 2008.
El 18 de septiembre de 2009, PayPal, Jackon y Barth publicaron una versión actualizada del esquema del protocolo en el documento original.
Esto condujo a la última «versión comunitaria» de la especificación «STS», publicada el 18 de diciembre de 2009, con revisiones basadas en los comentarios de la comunidad.
Finalmente, el 19 de noviembre de 2012 se publicó la especificación HSTS (RFC 6797) después de ser aprobada el 2 de octubre de 2012 por el Grupo de Dirección de Ingeniería de Internet (IESG), un organismo compuesto por el presidente del Grupo de Trabajo de Ingeniería de Internet (IETF) y los directores de área.
¿Por qué se introdujo HSTS?
HTTP se utiliza en varios transportes, generalmente el Protocolo de control de transmisión (TCP).
Sin embargo, TCP no proporciona protección de integridad, confidencialidad o identificación segura del host.
Esto llevó al desarrollo de Secure Sockets Layer (SSL) y su sucesor Transport Layer Security (TLS). SSL / TLS proporciona una capa de cifrado entre los protocolos de aplicación y TCP, comúnmente conocido como HTTPS.
En general, los agentes de usuario (como los navegadores web) emplearán varias políticas de seguridad locales para decidir cómo interactuar con un host, basándose en una negociación entre el servidor, las preferencias del usuario y su método de comunicación (HTTP o HTTPS).
Sin embargo, algunos agentes de usuario permiten a los usuarios elegir continuar interactuando con un sitio web cuando no pueden establecer una conexión segura. Esto puede ocurrir cuando la cadena de confianza de un certificado TLS no está validada, cuando ha expirado o cuando el nombre de dominio del host TLS aparece incorrectamente en el certificado TLS.
Este comportamiento se llama inseguridad de clic.
Si bien dar a los usuarios la opción de continuar usando un sitio web a pesar de la falta de HTTPS puede mantener a los usuarios contentos, puede introducir vectores de ataque que dejan a los usuarios abiertos a ciertos tipos de ataques cibernéticos , particularmente ataques de hombre en el medio (ataques MITM) , ataques de degradación y ataques de secuestro de sesión.
SSL-Stripping
Como HSTS permite que los sitios web declaren que solo son accesibles a través de una conexión segura, pueden evitar que los usuarios se conecten a ellos a través de cualquier conexión HTTP.
Esto evita una vulnerabilidad de seguridad conocida como SSL-stripping.
SSL-stripping es un ataque de degradación que fue presentado por Moxie Marlinspike en su charla de BlackHat Federal 2009 Nuevos trucos para derrotar a SSL en la práctica.
Un ataque de degradación es una forma de ataque criptográfico en un sistema informático o, en este caso, un protocolo de comunicaciones que hace que abandone su conexión cifrada (HTTPS) en favor de una conexión no cifrada (HTTP) más antigua que generalmente se proporciona para compatibilidad con versiones anteriores.
SSL-stripping se implementa como parte de un ataque man-in-the-middle donde el tráfico web es interceptado y redirigido desde la versión segura HTTPS del sitio web a una versión HTTP sin cifrar.
La razón principal por la que este ataque continúa siendo exitoso es que muchos sitios web continúan sin usar certificados TLS / SSL. Esto hace que sea imposible saber (sin conocimiento previo) si la falta de HTTPS en un sitio web se debe a un ataque de eliminación de SSL o porque no tienen un certificado TLS.
Además, no hay advertencias al usuario durante el proceso de degradación, lo que hace que el ataque sea difícil de detectar incluso para el usuario más vigilante.
Con la creación de una herramienta para automatizar completamente este tipo de ataque, representa un verdadero riesgo de ciberseguridad.
Secuestro de sesión
El secuestro de sesión o el secuestro de cookies es otra vulnerabilidad que se habilita a través de la inseguridad de clic.
El secuestro de sesión explota una sesión de ordenador válida para obtener acceso no autorizado a información o servicios.
Esto es particularmente relevante para los desarrolladores web, ya que las cookies se utilizan para mantener una sesión en muchos sitios web.
Si un sitio web no marca sus cookies como seguras, informando a los navegadores de que solo envíen cookies a través de HTTPS, un atacante puede robarlas de manera sencilla. Como las cookies no seguras se devuelven al host independientemente de la seguridad del transporte, dejándolas abiertas a ataques de intermediarios.
Una vez que un atacante tiene acceso a las cookies, puede suplantar al usuario en un sitio web legítimo.
¿Cómo funciona HSTS?
HSTS permite a los servidores web declarar que cualquier interacción de los navegadores web y otros agentes de usuario debe realizarse a través de conexiones HTTPS y no conexiones HTTP inseguras.
Un servidor puede implementar una política HSTS al proporcionar un encabezado de respuesta a través de una conexión HTTPS (los encabezados HSTS enviados a través de los encabezados de respuesta HTTP se ignoran).
El encabezado HSTS se llama «Strict-Transport-Security» y también especifica un período de tiempo durante el cual el agente de usuario solo debe acceder al servicio a través de solicitudes HTTPS.
Esto supone que, al acceder por primera vez a una web usando HTTPS, devuelve el encabezado Strict-Transport-Security, el navegador registra esta información, y al intentar cargar en el futuro el sitio utilizando HTTP automáticamente se usa HTTPS.
Cuando transcurra el tiempo de caducidad especificado por el encabezado Strict-Transport-Security, el siguiente intento de cargar el sitio a través de HTTP procederá normalmente, en lugar de usar HTTPS automáticamente.
Sin embargo, cada vez que el encabezado Strict-Transport-Security se entregue al agente de usuario, actualizará el tiempo de vencimiento de ese sitio, para que los sitios puedan actualizar esta información y evitar que expire el tiempo de espera.
Si fuera necesario deshabilitar HSTS, los servidores web pueden establecer la edad máxima en 0 (a través de una conexión HTTPS) para que caduque inmediatamente el encabezado HSTS, permitiendo el acceso a través de solicitudes HTTP.
Cuando una aplicación web emite una Política HSTS a los agentes de usuario, los agentes de usuario conformes se comportan de la siguiente manera:
Cualquier enlace inseguro se convierte automáticamente en enlaces seguros.
Si no se puede garantizar una conexión segura (por ejemplo, el servidor no tiene un certificado válido), el agente de usuario terminará la conexión y no permitirá que el usuario acceda al sitio web.
Lo más importante es que una Política HSTS evita la inseguridad de clics al no aceptar que el usuario final utilice la conexión insegura.
Ejemplo
Imagina que un miembro del personal utiliza un punto de acceso WiFi gratuito en una cafetería y comienza a navegar por la web, visitando el sistema de nóminas de tu organización.
Desafortunadamente, el punto de acceso que están utilizando es en realidad el ordenador portátil de un atacante e interceptan la solicitud HTTP original y redirigen a tu empleado a un clon de su sistema de nómina en lugar de lo real, exponiendo la información de identificación personal de tus empleados.
Si tu sistema de nómina usa HSTS y tu empleado lo visitó una vez usando HTTPS, entonces el navegador sabrá que solo usa HTTPS, evitando este tipo de ataque de hombre en el medio.
Limitaciones
Una limitación clave del uso de HSTS es que un usuario que no puede conectarse a través de HTTPS no podrá usar el sitio.
Además, como la Política de HSTS se comunica en un encabezado de respuesta, requiere que el agente de usuario visite primero el sitio web para saber que usa HSTS.
Esto significa que la solicitud inicial permanece desprotegida de los ataques activos si utiliza un protocolo inseguro como HTTP simple o si el URI para la solicitud inicial se obtuvo a través de un canal inseguro.
Esto también se aplicará a la primera solicitud después del período de actividad especificado en la edad máxima de HSTS.
Existe una amplia compatibilidad con el navegador para HSTS, incluidos Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera y Safari que abordan esta limitación al precargar las políticas de HSTS de la lista de precarga de HSTS. La lista HSTS contiene sitios web conocidos que admiten HSTS y se distribuyen con el navegador, por lo que utiliza HTTPS para la solicitud inicial de los sitios web enumerados.
Como este enfoque nunca puede escalar en toda la Web, ha habido discusiones para poder declarar HSTS en los registros DNS y acceder a ellos de forma segura a través de DNSSEC, lo que podría garantizar la validez.
Además, HSTS es ineficaz contra dominios de tipografía, ataques basados en DNS y ataques man-in-the-middle que sirven tráfico desde un dominio artificial que no está en la lista de precarga de HSTS.
Y como HSTS se basa en TLS, también se basa en la seguridad de TLS.
Cómo implementar HSTS
Si tu sitio está comprometido con HTTPS y deseas precargar HSTS, debes:
- Establecer un certificado válido
- Redirigir HTTP a HTTPS en el mismo host, si estás escuchando en el puerto 80
- Servir todos los subdominios a través de HTTPS. Debes admitir HTTPS para el subdominio www si existe un registro DNS para ese subdominio
- Establecer el encabezado HSTS en el dominio base para solicitudes HTTPS:
- La edad máxima debe ser de al menos 1 año
- Se debe especificar la directiva includeSubDomains
- Se debe especificar la directiva de precarga
- Si estás sirviendo una redirección adicional desde tu sitio HTTPS, esa redirección aún debe tener el encabezado HSTS (en lugar de la página web a la que redirige)
- Establecer el encabezado HSTS en el dominio base para solicitudes HTTPS:
Te recomendamos comenzar con los siguientes pasos:
- Examina todos los subdominios anidados de tu sitio y asegúrate de que funcionen sobre HTTPS.
- Habilita HSTS para todas las respuestas HTTPS y aumenta la edad máxima por etapas. Durante cada etapa, verifica si hay páginas rotas, controla las métricas del sitio y soluciona los problemas que surjan y luego espera la edad máxima de la etapa antes de continuar. Puedes usar los siguientes valores de encabezado:
- 5 minutos – Seguridad de transporte estricta: edad máxima = 300; includeSubDomains
- 1 semana – Seguridad de transporte estricta: edad máxima = 604800; includeSubDomains
- 1 mes – Seguridad de transporte estricta: edad máxima = 2592000; includeSubDomains
- Una vez que estés seguro de que no hay problemas, aumenta la edad máxima a 2 años y envía tu sitio a la lista de precarga de HSTS con la directiva de precarga:
- 2 años – Seguridad de transporte estricta: edad máxima = 63072000; includeSubDomains; precargar
- Puedes agregar tu sitio web a la lista de precarga de HSTS a través de https://hstspreload.org/
¿Qué navegadores admiten HSTS?
HSTS es admitido por los siguientes navegadores:
- Chromium y Google Chrome desde la versión 4.0.211.0
- Firefox desde la versión 4; con Firefox 17, Mozilla integra una lista de sitios web compatibles con HSTS
- Opera desde la versión 12
- Safari desde OS X Mavericks versión 10.9
- Internet Explorer 11 en Windows 8.1 y Windows 7 cuando está instalado KB 3058515
- Microsoft Edge e Internet Explorer 11 en Windows 10
- BlackBerry 10 Browser y WebView desde BlackBerry OS 10.3.3
¿Es HSTS completamente seguro?
Desafortunadamente, la primera vez que accedes al sitio web, HSTS no te protege. Si el sitio web agrega un encabezado HSTS a una conexión HTTP, ese encabezado se ignora. Esto se debe a que un atacante puede eliminar o agregar encabezados durante un ataque de hombre en el medio. No se puede confiar en el encabezado HSTS a menos que se entregue a través de HTTPS.
También debes saber que el HSTS max-agese actualiza cada vez que tu navegador lee el encabezado y el valor máximo es de dos años. Esto significa que la protección es permanente siempre que no pasen más de dos años entre tus visitas.
Si no visitas un sitio web durante dos años, se trata como un sitio nuevo. Al mismo tiempo, si sirve el encabezado HSTS con max-age0, el navegador tratará el sitio como uno nuevo en el próximo intento de conexión.
Puedes usar un método de protección adicional llamado lista de precarga de HSTS. El proyecto Chromium mantiene una lista de sitios web que usan HSTS y la lista se distribuye con navegadores. Si agregas tu sitio web a la lista de precarga, el navegador primero verifica la lista interna y, por lo tanto, nunca se accede al sitio web a través de HTTP, ni siquiera durante el primer intento de conexión. Este método no forma parte del estándar HSTS, pero lo utilizan todos los principales navegadores.
El único método actualmente conocido que podría usarse para evitar HSTS es un ataque basado en NTP. Si el ordenador del cliente es susceptible a un ataque NTP, se puede engañar para que caduque la política HSTS y acceda al sitio una vez con HTTP.