La seguridad de transporte estricta de HTTP ( HSTS ) es un mecanismo de políticas que ayuda a proteger los sitios web contra ataques de intermediarios, como ataques de degradación de protocolo [1] y secuestro de cookies . Permite a los servidores web declarar que los navegadores web (u otros agentes de usuario que cumplan con las normas ) deben interactuar automáticamente con ellos utilizando únicamente conexiones HTTPS , que proporcionan seguridad de la capa de transporte (TLS/SSL), a diferencia del protocolo HTTP inseguro que se utiliza solo. HSTS es un protocolo de seguimiento de estándares de IETF y se especifica en RFC 6797.
La política HSTS se comunica por el servidor al agente de usuario a través de un campo de encabezado de respuesta HTTP llamado Strict-Transport-Security. La política HSTS especifica un período de tiempo durante el cual el agente de usuario solo debe acceder al servidor de manera segura. [2] : §5.2 Los sitios web que utilizan HSTS a menudo no aceptan HTTP de texto sin formato, ya sea rechazando conexiones a través de HTTP o redirigiendo sistemáticamente a los usuarios a HTTPS (aunque esto no es requerido por la especificación). La consecuencia de esto es que un agente de usuario que no sea capaz de hacer TLS no podrá conectarse al sitio.
La protección solo se aplica después de que un usuario haya visitado el sitio al menos una vez, basándose en el principio de " confianza en el primer uso ". La forma en que funciona esta protección es que cuando un usuario ingresa o selecciona una URL HTTP (no HTTPS) para acceder al sitio, el cliente, como un navegador web, se actualizará automáticamente a HTTPS sin realizar una solicitud HTTP, lo que evita que se produzca cualquier ataque de intermediario HTTP.
La especificación HSTS se publicó como RFC 6797 el 19 de noviembre de 2012 después de ser aprobada el 2 de octubre de 2012 por el IESG para su publicación como Propuesta de Estándar RFC . [3] Los autores la presentaron originalmente como Borrador de Internet el 17 de junio de 2010. Con la conversión a Borrador de Internet, el nombre de la especificación se modificó de "Seguridad de Transporte Estricta" (STS) a "Seguridad de Transporte Estricta HTTP", porque la especificación se aplica solo a HTTP . [4] Sin embargo, el campo de encabezado de respuesta HTTP definido en la especificación HSTS sigue llamándose "Seguridad de Transporte Estricta".
La última versión denominada "comunitaria" de la especificación entonces denominada "STS" se publicó el 18 de diciembre de 2009, con revisiones basadas en los comentarios de la comunidad. [5]
El borrador original de la especificación de Jeff Hodges de PayPal , Collin Jackson y Adam Barth se publicó el 18 de septiembre de 2009. [6]
La especificación HSTS se basa en el trabajo original de Jackson y Barth, tal como se describe en su artículo "ForceHTTPS: Protección de sitios web de alta seguridad contra ataques de red". [7]
Además, HSTS es la realización de una faceta de una visión general para mejorar la seguridad web, propuesta por Jeff Hodges y Andy Steingruble en su artículo de 2010 The Need for Coherent Web Security Policy Framework(s) (La necesidad de un marco de políticas de seguridad web coherente) . [8]
Un servidor implementa una política HSTS al proporcionar un encabezado a través de una conexión HTTPS (los encabezados HSTS a través de HTTP se ignoran). [1] Por ejemplo, un servidor podría enviar un encabezado de modo que las futuras solicitudes al dominio para el próximo año (la edad máxima se especifica en segundos; 31 536 000 es igual a un año no bisiesto) utilicen solo HTTPS: Strict-Transport-Security: max-age=31536000.
Cuando una aplicación web emite una política HSTS a los agentes de usuario, los agentes de usuario que cumplen con la normativa se comportan de la siguiente manera: [2] : §5
http://example.com/some/page/se modificarán https://example.com/some/page/ antes de acceder al servidor).La política HSTS ayuda a proteger a los usuarios de aplicaciones web contra algunos ataques de red pasivos ( espionaje ) y activos . [2] : §2.4 Un atacante intermediario tiene una capacidad muy reducida para interceptar solicitudes y respuestas entre un usuario y un servidor de aplicaciones web mientras el navegador del usuario tenga la política HSTS vigente para esa aplicación web.
La vulnerabilidad de seguridad más importante que HSTS puede solucionar son los ataques de intermediarios de eliminación de SSL , introducidos públicamente por primera vez por Moxie Marlinspike en su charla de 2009 en BlackHat Federal "Nuevos trucos para derrotar a SSL en la práctica". [9] [10] El ataque de eliminación de SSL (y TLS ) funciona convirtiendo de forma transparente una conexión HTTPS segura en una conexión HTTP simple. El usuario puede ver que la conexión no es segura, pero, fundamentalmente, no hay forma de saber si la conexión debería ser segura. En el momento de la charla de Marlinspike, muchos sitios web no usaban TLS/SSL, por lo tanto, no había forma de saber (sin conocimiento previo) si el uso de HTTP simple se debía a un ataque o simplemente a que el sitio web no había implementado TLS/SSL. Además, no se presentan advertencias al usuario durante el proceso de degradación, lo que hace que el ataque sea bastante sutil para todos, excepto para los más vigilantes. La herramienta sslstrip de Marlinspike automatiza completamente el ataque. [ cita requerida ]
HSTS soluciona este problema [2] : §2.4 informando al navegador que las conexiones al sitio siempre deben usar TLS/SSL. El atacante puede eliminar el encabezado HSTS si se trata de la primera visita del usuario. Google Chrome , Mozilla Firefox , Internet Explorer y Microsoft Edge intentan limitar este problema al incluir una lista "precargada" de sitios HSTS. [11] [12] [13] Lamentablemente, esta solución no se puede escalar para incluir todos los sitios web de Internet. Consulte las limitaciones a continuación.
HSTS también puede ayudar a evitar que las credenciales de inicio de sesión de un sitio web basado en cookies sean robadas por herramientas ampliamente disponibles como Firesheep . [14]
Debido a que HSTS tiene un límite de tiempo, es sensible a ataques que implican cambiar la hora de la computadora de la víctima, por ejemplo, utilizando paquetes NTP falsos . [15]
La solicitud inicial permanece desprotegida de 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 . [2] : §14.6 Lo mismo se aplica a la primera solicitud después del período de actividad especificado en la Política HSTS anunciada max-age(los sitios deben establecer un período de varios días o meses dependiendo de la actividad y el comportamiento del usuario).
Google Chrome , Mozilla Firefox e Internet Explorer / Microsoft Edge abordan esta limitación implementando una "lista precargada de HSTS", que es una lista que contiene sitios conocidos que admiten HSTS. [16] [11] [12] [13] Esta lista se distribuye con el navegador para que también use HTTPS para la solicitud inicial a los sitios enumerados. Como se mencionó anteriormente, estas listas precargadas no pueden escalar para cubrir toda la Web. Una posible solución podría lograrse utilizando registros DNS para declarar la política HSTS y acceder a ellos de forma segura a través de DNSSEC , opcionalmente con huellas digitales de certificados para garantizar la validez (lo que requiere ejecutar un solucionador de validación para evitar problemas de última milla ). [17]
Junade Ali ha señalado que HSTS es ineficaz contra el uso de dominios falsos; al utilizar ataques basados en DNS, es posible que un interceptor intermediario sirva tráfico desde un dominio artificial que no está en la lista de precarga de HSTS, [18] esto puede ser posible mediante ataques de suplantación de DNS, [19] o simplemente un nombre de dominio que se parezca engañosamente al nombre de dominio real, como www.example.org en lugar de www.example.com .
Incluso con una lista precargada de HSTS, HSTS no puede evitar ataques avanzados contra TLS, como los ataques BEAST o CRIME introducidos por Juliano Rizzo y Thai Duong. Los ataques contra TLS son ortogonales a la aplicación de políticas de HSTS. Tampoco puede proteger contra ataques al servidor: si alguien lo compromete, servirá con gusto cualquier contenido a través de TLS.
HSTS se puede utilizar para etiquetar de forma casi indeleble los navegadores que visitan el sitio con datos de identificación recuperables ( supercookies ) que pueden persistir dentro y fuera de los modos de privacidad de " incógnito " del navegador. Al crear una página web que realiza múltiples solicitudes HTTP a dominios seleccionados, por ejemplo, si se utilizan veinte solicitudes de navegador a veinte dominios diferentes, teóricamente se pueden distinguir más de un millón de visitantes (2 20 ) debido a las solicitudes resultantes que llegan a través de HTTP frente a HTTPS; siendo este último los "bits" binarios registrados previamente establecidos anteriormente a través de los encabezados HSTS. [20]
Dependiendo de la implementación real, existen ciertas amenazas (por ejemplo, ataques de inyección de cookies) que se pueden evitar siguiendo las mejores prácticas.
includeSubDomainsdirectiva. [2] : §6.1.2 