La importancia de un adecuado HTTP Strict Transport Security en el servidor Web

Modificado por última vez en Martes, 05 Abril 2016 17:09
(0 votos)

internet explorer security

Semánticamente hay distintas formas para enviar cabeceras HSTS

Alrededor del 95 por ciento de los servidores HTTPS son vulnerables al secuestro de conexiones, abriendo la puerta a los hackers para lanzar ataques man-in-the-middle y otros devastadores atraques cibernéticos. Esto es según un estudio de Netcraft publicado hace una semana. La razón de por qué nos concierne esta situación: Sólo el 5 por ciento de los servidores HTTPS hace una aplicación correcta de la HTTP Strict Transport Security.

Sobre HTTP Strict Transport Security

Seguridad de transporte HTTP estricta (HTTP Strict Transport Security - HSTS) es un método para aplicaciones de Internet que asegura que sólo se utilizan conexiones TLS para apoyar un transporte seguro. Protege a los usuarios contra espionaje pasivo y ataques activos man-in-the-middle (MITM). También hace cumplir medidas de seguridad estrictas, como la prevención de contenido mixto y anulaciones de certificados con click-through, y protege contra errores del servidor web si el JavaScript se carga a través de una conexión insegura. HSTS sirve como un paraguas seguro contra todos estos ataques.

Las aplicaciones web deben operar bajo la suposición de que un hacker puede ejecutar ataques MITM a través de una conexión HTTP de texto plano para cualquier dominio/subdominio, por ejemplo, con la ayuda de entradas de DNS maliciosas. Los piratas informáticos no pueden, sin embargo, interceptar el tráfico HTTPS válido sobre cualquiera de los dominios/subdominios. Por lo tanto, es aconsejable proteger dominios/subdominios tanto como sea posible usando una política HSTS apropiada.

La implementación de HSTS

Semánticamente hay distintas formas para enviar cabeceras HSTS, como se define en el RFC 6797 :

"¢ Strict-Transport-Security: max-age=31536000
La política HSTS sólo se aplica en el ámbito del servidor HSTS que lo emite y permanece en efecto por un año.

"¢ Strict-Transport-Security: max-age=31536000; includeSubDomains
La política HSTS se aplica al dominio del host emisor, así como sus subdominios y permanece en efecto por un año.

"¢ Strict-Transport-Security: max-age=0
Dirige el navegador para eliminar toda la política HSTS.

Yo utilizo en mi servidor la siguiente:

# HSTS (mod_headers is required) (31536000 seconds = 1 año)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

En el ejemplo anterior, el navegador recordará la política HSTS durante un año. La política se actualiza cada vez que el navegador ve el encabezado de nuevo, por lo que si un usuario visita https://www.facebook.com al menos una vez al año, va a estar protegido por HSTS por tiempo indefinido.

Además en el archivo .htaccess de cada dominio es recomendable incluir lo siguiente:

# Detect the LB header and set the header accordingly for the application
SetEnvIf X-Forwarded-Proto https HTTPS=on

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

qualys para vistaalmar.es

Buenas prácticas HSTS

Hay algunas buenas prácticas y sencillas para HSTS

1. La protección más fuerte es asegurar que todos los recursos solicitados sólo utilizan TLS con un encabezado HSTS bien formado. Qualys recomienda proporcionar una cabecera HSTS sobre todos los recursos HTTPS en el dominio de destino.

2. Es aconsejable asignar el valor de la directiva max-age para que sea mayor que 10368000 segundos (120 días) e idealmente en 31536000 (un año). Los sitios web deben apuntar la rampa hasta el valor max-age para garantizar mayor seguridad para una larga duración actual para el dominio y/o subdominios.

3. La sección 14.4 del RFC 6797 defiende que una aplicación web debe tener como objetivo añadir siempre que sea posible en la definición de políticas la directiva 'includeSubDomain'. La presencia de la directiva garantiza que la política HSTS se aplica al dominio del host emisor y a todos sus subdominios, por ejemplo, example.com y www.example.com.

4. La aplicación nunca debe enviar una cabecera HSTS con más de una cabecera HTTP de texto, ya que al hacerlo hace que la conexión SSL sea vulnerable a los ataques de extracción.

5. No se recomienda proporcionar una política HSTS a través del atributo http-equiv de una etiqueta meta. De acuerdo con HSTS RFC 6797, los agentes de usuario no tienen en cuenta el atributo http-equiv="Strict-Transport-Security" en elementos <meta> en el contenido recibido.

La lista de precarga

HSTS sufre un problema de la gallina y el huevo. Si un navegador nunca ha visitado previamente un sitio web específico con HSTS habilitado, el navegador no va a ser consciente de que el sitio web tiene HSTS habilitado e intentará una conexión HTTP que es propensa a un ataque de desmontaje SSL. Los navegadores que soportan HSTS han tratado de mitigar el problema mediante el envío de una lista de "pre-carga" que no es sino una lista de servidores HSTS conocidos.

solicitus de preload en Chrome

Por ejemplo: https://www.chromium.org/hsts tiene toda la lista de precarga para Chrome. Los dominios incluidos en la lista de la precarga del navegador se pueden configurar con el HSTS listo para usar. Para incluir tu aplicación web en la lista HSTS precargada, envía una solicitud a https://hstspreload.appspot.com/ .

A medida que las transiciones a web van totalmente a HTTPS en el corto plazo y los navegadores pueden iniciar el desmantelamiento de HTTP plano y cambiar a a HTTPS, la lista de precarga HSTS con el tiempo puede llegar a ser innecesaria.

El uso de "˜includeSubDomains"™

Puede no ser factible usar la directiva "˜includeSubDomains"™ en el dominio de nivel superior, por ejemplo, cuando está presente un subdominio que no funciona sobre HSTS. Las posibilidades podrían ser las siguientes:

1. Es caro suministrar a todos los subdominios del servidor un certificado firmado por una CA válida. Si HSTS está habilitada, el navegador prohíbe a los usuarios el uso de certificados de firma propia para los subdominios.

2. No podrá cargar recursos no seguros y romperá las páginas que han trabajado sin problemas a través de TLS cuando no se implementó ninguna política HSTS.

Incluir la directiva SubDomains se recomienda sólo cuando todos los sitios dentro de la organización para el nombre de dominio en cuestión requieren TLS/SSL. Es necesario evaluar el impacto en los servicios existentes de 3ª partes, como el correo electrónico o DNS CNAMES para CDNs antes de añadir la directiva "˜includeSubDomains"™.

Conclusiones

Debido a que HSTS proporciona protección contra una amplia gama de ataques, es apoyada ampliamente por los navegadores y puede ser configurada con una configuración de una sola línea, es muy recomendable su uso para todas las aplicaciones Web orientados a Internet. Y se recomienda la incorporación en todas las herramientas que se utilizan de prácticas de codificación segura y la conciencia de incluir HSTS al principio del ciclo de desarrollo para asegurar que los desarrolladores piensen acerca de la seguridad desde el primer día.

Lee también:

HTTP Strict Transport Security
HSTS web developer documentation mantenido por la comunidad de Mozilla


Comentarios (0)

No hay comentarios escritos aquí

Deja tus comentarios

  1. Publicar comentario como invitado. Regístrate o ingresaa tu cuenta
Archivos adjuntos (0 / 3)
Compartir su ubicación
close

Recibe gratis nuestros nuevos artículos!

Serás el primero en conocer las novedades y noticias que pasan en Internet, nuestros tutoriales, trucos y más.

Escribe tu email:

Se abrirá una nueva ventana deFeedBurner a la izquierda de la página y habrás de validar un Captcha.

Lee nuestras Política de privacidad & Política de cookies
Puedes darte de baja de la lista de correo electrónico en cualquier momento