Seguridad de transporte estricta HTTP
Mecanismo de protección del sitio web

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.

Historial de especificaciones

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]

Descripción general del mecanismo HSTS

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 

  1. Convierte automáticamente cualquier enlace inseguro que haga referencia a la aplicación web en enlaces seguros (por ejemplo, http://example.com/some/page/se modificarán https://example.com/some/page/ antes de acceder al servidor).
  2. Si no se puede garantizar la seguridad de la conexión (por ejemplo, el certificado TLS del servidor no es confiable), el agente de usuario debe finalizar la conexión [2] : §8.4  y no debe permitir que el usuario acceda a la aplicación web. [2] : §12.1 

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.

Aplicabilidad

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]

Limitaciones

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).

Soluciones con lista de precarga

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.

Cuestiones de privacidad

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]

Compatibilidad con navegadores

Página de configuración de seguridad en Chromium 45, que muestra el estado de la política de seguridad para el dominio "en.wikipedia.org".
Página de configuración para la seguridad de transporte estricta HTTPS en Chromium 45, que muestra el estado de la política de seguridad para el dominio "en.wikipedia.org".

Mejores prácticas de implementación

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.

  • Los hosts HSTS deben declarar la política HSTS en su nombre de dominio de nivel superior. Por ejemplo, un host HSTS en https://sub.example.com también debe responder con el encabezado HSTS en https://example.com. El encabezado debe especificar la includeSubDomainsdirectiva. [2] : §6.1.2 
  • Además de la implementación de HSTS, un host para https://www.example.com debe incluir una solicitud a un recurso de https://example.com para asegurarse de que HSTS para el dominio principal esté configurado y proteja al usuario de posibles ataques de inyección de cookies realizados por un MITM que inyectaría una referencia al dominio principal (o incluso http://nonexistentpeer.example.com), a la que luego respondería el atacante. [2] : §11.4 

Véase también

Referencias

  1. ^ abc "Strict-Transport-Security". MDN Web Docs . Mozilla . Archivado desde el original el 20 de marzo de 2020 . Consultado el 31 de enero de 2018 .
  2. ^ abcdefghi J. Hodges; C. Jackson; A. Barth (noviembre de 2012). Seguridad de transporte estricta de HTTP (HSTS). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6797 . ISSN  2070-1721. RFC 6797. Norma propuesta.
  3. ^ "[websec] Acción de protocolo: 'Seguridad de transporte estricta HTTP (HSTS)' según el estándar propuesto (draft-ietf-websec-strict-transport-sec-14.txt)". 2 de octubre de 2012. Archivado desde el original el 29 de enero de 2017. Consultado el 2 de octubre de 2012 .
  4. ^ Hodges, Jeff (30 de junio de 2010). «Re: [HASMAT] Nombre "STS" (antes: IETF BoF @IETF-78 Maastricht: HASMAT...)». Archivado desde el original el 2 de febrero de 2017. Consultado el 22 de julio de 2010 .
  5. ^ "Seguridad estricta en el transporte -06". 18 de diciembre de 2009. Archivado desde el original el 21 de febrero de 2017. Consultado el 23 de diciembre de 2009 .
  6. ^ "Seguridad estricta en el transporte -05". 18 de septiembre de 2009. Archivado desde el original el 24 de febrero de 2020. Consultado el 19 de noviembre de 2009 .
  7. ^ "ForceHTTPS: Protección de sitios web de alta seguridad contra ataques de red". Abril de 2008. Archivado desde el original el 28 de febrero de 2020. Consultado el 19 de noviembre de 2009 .
  8. ^ Hodges, Jeff; Steinguebl, Andy (29 de octubre de 2010). "La necesidad de marcos de políticas de seguridad web coherentes". Archivado desde el original el 14 de agosto de 2017. Consultado el 21 de noviembre de 2012 .
  9. ^ Marlinspike, Moxie (2009). Nuevos trucos para derrotar a SSL en la práctica (PDF) . Black Hat Briefings . Washington, DC. Archivado (PDF) del original el 30 de diciembre de 2014. Consultado el 15 de marzo de 2012 .
  10. ^ Cómo vencer a SSL con Sslstrip en YouTube
  11. ^ ab Langley, Adam (8 de julio de 2010). «Seguridad estricta en el transporte». The Chromium Projects . Archivado desde el original el 1 de septiembre de 2019. Consultado el 22 de julio de 2010 .
  12. ^ abc Keeler, David (1 de noviembre de 2012). «Precarga de HSTS». Blog de seguridad de Mozilla . Archivado desde el original el 24 de febrero de 2020. Consultado el 6 de febrero de 2014 .
  13. ^ ab Bell, Mike; Walp, David (16 de febrero de 2015). «HTTP Strict Transport Security llega a Internet Explorer». Archivado desde el original el 15 de noviembre de 2015. Consultado el 16 de febrero de 2015 .
  14. ^ Hodges, Jeff (31 de octubre de 2010). «Firesheep y HSTS (HTTP Strict Transport Security)». Archivado desde el original el 23 de junio de 2016. Consultado el 8 de marzo de 2011 .
  15. ^ Selvi, Jose (17 de octubre de 2014). Cómo sortear la seguridad de transporte estricta de HTTP (PDF) . Black Hat Briefings . Ámsterdam. Archivado (PDF) del original el 22 de octubre de 2014 . Consultado el 22 de octubre de 2014 .
  16. ^ "Lista de precarga de Chromium HSTS". cs.chromium.org . Archivado desde el original el 18 de febrero de 2020. Consultado el 10 de julio de 2019 .
  17. ^ Butcher, Simon (11 de septiembre de 2011). «Seguridad de transporte estricta HTTP». Archivado desde el original el 26 de abril de 2019. Consultado el 27 de marzo de 2012 .
  18. ^ Ali, Junade (20 de octubre de 2017). "Performing & Preventing SSL Stripping: A Plain-English Primer" (Realizar y prevenir la eliminación de SSL: una introducción en lenguaje sencillo). Blog de Cloudflare . Archivado desde el original el 14 de diciembre de 2019. Consultado el 7 de diciembre de 2017 .
  19. ^ Maksutov, AA; Cherepanov, IA; Alekseev, MS (2017). Detección y prevención de ataques de suplantación de DNS . Simposio siberiano sobre ciencia e ingeniería de datos (SSDSE) de 2017. págs. 84-87. doi :10.1109/SSDSE.2017.8071970. ISBN 978-1-5386-1593-5. Número de identificación del sujeto  44866769.
  20. ^ "La supercookie HSTS que te obliga a elegir: "¿privacidad o seguridad?" -". sophos.com . 2 de febrero de 2015. Archivado desde el original el 11 de febrero de 2020 . Consultado el 1 de diciembre de 2015 .
  21. ^ The Chromium Developers (17 de noviembre de 2010). «Seguridad estricta en el transporte: los proyectos de Chromium». Archivado desde el original el 20 de marzo de 2020. Consultado el 17 de noviembre de 2010 .
  22. ^ Hodges, Jeff (18 de septiembre de 2009). «fyi: especificación de seguridad de transporte estricta». Archivado desde el original el 29 de febrero de 2020. Consultado el 19 de noviembre de 2009 .
  23. ^ Opera Software ASA (23 de abril de 2012). «Compatibilidad con especificaciones web en Opera Presto 2.10». Archivado desde el original el 20 de junio de 2018. Consultado el 8 de mayo de 2012 .
  24. ^ Langley, Adam [@agl__] (20 de diciembre de 2013). «Confirmado. Consulte ~/Library/Cookies/HSTS.plist. Incluye precargas de Chromium a partir de cierta fecha y procesa encabezados HSTS» ( Tweet ). Archivado desde el original el 9 de mayo de 2019 . Consultado el 20 de diciembre de 2013 – vía Twitter .
  25. ^ "HTTP Strict Transport Security llega a Internet Explorer 11 en Windows 8.1 y Windows 7". windows.com . Archivado desde el original el 27 de noviembre de 2019 . Consultado el 12 de junio de 2015 .
  26. ^ "Estado y hoja de ruta de la plataforma web Internet Explorer". Archivado desde el original el 29 de junio de 2015 . Consultado el 14 de abril de 2014 .
  27. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". 22 de enero de 2015. Archivado desde el original el 29 de noviembre de 2019. Consultado el 23 de enero de 2015 .
  • Grupo de trabajo de seguridad web de la IETF
  • Security Now 262: Seguridad estricta en el transporte
  • Proyecto de seguridad de aplicaciones web abiertas (OWASP): descripción de HSTS
  • Prueba de HSTS y fijación de clave pública del navegador en línea
  • Envío de precarga de HSTS para Google Chrome, Mozilla Firefox, Safari, IE 11 y Edge
  • Lista de precargas de Chromium HSTS
  • Seguridad de transporte estricta en documentos web de MDN
Obtenido de "https://es.wikipedia.org/w/index.php?title=Seguridad_estricta_del_transporte_HTTP&oldid=1258010500"