Implicaciones de seguridad de los encabezados de respuesta HTTP

Cuando un servidor web recibe una solicitud HTTP, la procesa y envía una respuesta que contiene el recurso solicitado y otra información en forma de encabezados de respuesta HTTP. Estos encabezados proporcionan datos importantes, como fechas de última modificación, tipos de contenido y configuraciones de caché. Luego, el navegador usa esta información para decidir cómo mostrar o almacenar ese recurso. Este proceso ayuda a garantizar una comunicación eficiente entre los servidores web y los navegadores.

Desde la perspectiva de la ciberseguridad, los encabezados de respuesta HTTP representan posibles vectores de ataque y oportunidades para agregar capas de defensa. Pueden contener datos confidenciales, como tokens de autenticación, cookies e ID de sesión que, una vez obtenidos, permiten que los atacantes eludan los controles de autorización o secuestren cuentas de usuario. Pero también podemos usarlos para controlar el almacenamiento en caché, especificar el tipo de contenido que se devuelve y prevenir ataques como el scripting entre sitios (XSS) y el clickjacking.

Los encabezados de respuesta HTTP ofrecen varias funciones de seguridad, como autenticación, seguimiento del agente de usuario, prevención de XSS y aplicación del uso de HTTPS. Aunque ciertos encabezados HTTP, como Etag, Last-Modified y Content-Type, no son útiles con fines de seguridad, los encabezados Content Security Policy (CSP), HTTP Strict Transport Security (HSTS) y X-Frame-Options ofrecen oportunidades para reforzar nuestros servidores.

Este artículo destaca varios encabezados HTTP que afectan la seguridad y recomienda prácticas para aprovechar los encabezados de respuesta HTTP y proteger las aplicaciones web.

Cómo aprovechar los encabezados de respuesta HTTP para la seguridad

Podemos usar los encabezados de respuesta HTTP para mitigar varios tipos de vulnerabilidades explotables.

Vulnerabilidades que debes tener en cuenta en los encabezados de respuesta HTTP

Los encabezados de respuesta HTTP adecuados mitigan los ataques directos y también ayudan a abordar vulnerabilidades que no los involucran directamente. Estos son algunos ejemplos de distintos tipos de ataques y vulnerabilidades:

• Falsificación de solicitudes entre sitios (CSRF): Los atacantes pueden usar CSRF, también conocido como ataque de un clic, para obligar al navegador web de un usuario a realizar acciones no deseadas en su nombre.

• Secuestro de sesión: Los atacantes obtienen acceso no autorizado al robar los ID de sesión de usuarios autenticados y secuestrar sus sesiones activas sin credenciales, como pares de nombre de usuario y contraseña, para eludir los sistemas de autenticación tradicionales.

• Filtración de datos: Los encabezados de respuesta HTTP pueden contener contraseñas, números de tarjetas de crédito y otra información confidencial que podría filtrarse si no se configura correctamente.

• Ataques de intermediario (MITM): Los atacantes usan ataques MITM para interceptar, modificar y bloquear las comunicaciones entre dos partes durante una transacción. Ninguna de las partes sabe que la otra se está comunicando con un tercero no autorizado.

• Ataques de clickjacking: Al explotar debilidades en los conjuntos de marcos HTML de un sitio web, los atacantes pueden enviar contenido falsificado a los usuarios. Al hacer clic, los usuarios realizan acciones no deseadas o divulgan información confidencial sin saberlo.

Mantener la seguridad de las aplicaciones web es fundamental, especialmente ante la gran cantidad de posibles vías de ataque. En los últimos años, hemos visto un aumento de las brechas de seguridad de alto perfil y gran impacto. Por ejemplo:

• En una filtración reciente de datos que afectó a TransUnion, una empresa de informes crediticios, los atacantes retuvieron la información de más de 50 millones de personas sudafricanas y exigieron un rescate de 15 millones de dólares.

• Los plugins de WordPress relacionados con el RGPD pueden ser vulnerables a ataques XSS y CSRF. Un plugin afectó a 10,000 sitios web en 2018 y otro dejó expuestos 700,000 sitios web en 2020.

• Las grandes empresas tecnológicas siempre son objetivos atractivos. Por suerte para Uber, la empresa de transporte compartido, las vulnerabilidades de CSRF y secuestro de sesión solo le han costado alrededor de 5,000 dólares en recompensas por errores otorgadas.

Dada la frecuencia y la magnitud de los ataques, está claro que aumentar y mantener la seguridad —incluso mediante encabezados HTTP— es indispensable.

Encabezados de respuesta HTTP que afectan la seguridad

La filtración de datos es una vulnerabilidad directamente relacionada con los encabezados de respuesta HTTP. Los ataques CSRF, de secuestro de sesión y MITM no necesariamente los involucran. Sin embargo, podemos mitigarlos mediante encabezados HTTP seguros —como CSP y HTTP Strict Transport Security (HSTS)— y siguiendo las prácticas recomendadas al usar otros encabezados que afectan la seguridad, como los que se describen a continuación.

Encabezado HTTP Strict Transport Security

El encabezado de respuesta HSTS protege las aplicaciones de ataques MITM, filtraciones de datos y clickjacking. Este encabezado obliga a que toda la comunicación entre el navegador y el servidor se realice mediante conexiones HTTPS en lugar de HTTP sin cifrar. Evita que los atacantes redirijan el tráfico a través de sus servidores proxy maliciosos para acceder a los datos confidenciales que se envían entre las partes o manipularlos sin que ninguna lo note.

HSTS contiene información sobre las políticas de seguridad de un sitio web, como:

• Cuánto tiempo permanecerá activa la conexión (edad máxima).

• Si el alcance de la protección incluye los subdominios.

• Qué tipos de certificados se aceptan.

Para aprovechar al máximo el encabezado de respuesta HSTS, siempre debemos establecer un valor de edad máxima. Este debe corresponder al tiempo durante el cual queremos que los clientes recuerden conectarse de forma segura antes de enviar otra solicitud a través del túnel TLS/SSL.

Encabezado Content-Security-Policy

CSP es importante para defenderse de distintos tipos de ataques. Permite que los desarrolladores agreguen a una lista de permitidos los recursos y sus orígenes autorizados, definan directivas, determinen si permiten scripts en línea o eval() y decidan si permiten atributos de estilo en HTML.

El encabezado de respuesta HTTP Content-Security-Policy permite especificar los dominios y recursos permitidos o bloqueados en el contenido de un sitio web. Protege contra XSS y las vulnerabilidades mencionadas, además de otras actividades maliciosas, como clickjacking, inyección de datos, inyección de código, CSRF y acceso no autorizado a información confidencial. CSP contiene directivas que indican a los navegadores cómo manejar las solicitudes de fuentes no confiables fuera de nuestro dominio, incluidas las solicitudes para cargar scripts, imágenes y otros recursos explotables.

Estas son algunas pautas para configurar el encabezado CSP y defenderse de forma proactiva contra las vulnerabilidades:

• Siempre que sea posible, elige políticas que bloqueen la actividad en lugar de permitirla. Así se bloquearán de forma predeterminada las solicitudes de fuentes no confiables fuera de tu dominio.

• Usa subdominios comodín (el prefijo *.<your-domain-name> antes del nombre de tu dominio principal).

• Limita el acceso a fuentes confiables conocidas en lugar de permitir solicitudes de cualquier fuente. También incluye directivas que indiquen a los navegadores cómo deben manejar ciertas solicitudes de fuentes no confiables fuera de nuestro dominio, como las solicitudes para cargar scripts, imágenes y otros recursos explotables.

Una postura de seguridad estricta garantiza que solo los clientes autorizados puedan ver información confidencial y, a la vez, previene las filtraciones de datos por rutas posteriores no previstas. También podemos utilizar mecanismos estrictos de validación, como Subresource Integrity (SRI), que ayudan a verificar la integridad de los recursos de un sitio web y a garantizar que un atacante no los haya manipulado.

Al combinar SRI con CSP, podemos garantizar que solo se carguen en nuestras páginas web recursos de terceros confiables y sin alteraciones.

Encabezado X-Content-Type-Options

Podemos aprovechar el encabezado X-Content-Type-Options para indicar a los navegadores que nunca intenten detectar automáticamente el tipo de archivo o contenido que se sirve. Esto dificulta mucho que un atacante inyecte código malicioso en un sitio web, ya que el navegador no podrá analizar ni ejecutar archivos de scripts arbitrarios que se envíen junto con el contenido. De esta manera, el encabezado X-Content-Type-Options ofrece una primera línea de defensa contra el contenido malicioso y los ataques XSS.

Al configurar y usar este encabezado, asegúrate de que todos los sitios sirvan contenido con tipos MIME estrictos especificados. Evita usar comodines (*) en esos valores siempre que sea posible. Especificar los tipos de archivo concretos indica a los navegadores con precisión qué recursos deben esperar y elimina la necesidad de detectarlos.

Encabezado X-Frame-Options

X-Frame-Options protege las aplicaciones web contra ataques de clickjacking. Contiene una directiva que indica al navegador si puede mostrar su contenido dentro de un elemento <iframe> en un sitio web de terceros.

Hay dos directivas de uso común. DENY impide cualquier intento de mostrar el recurso solicitado en marcos de otros sitios. SAMEORIGIN solo permite la solicitud si ambas páginas se alojan bajo la misma política de origen. Esta configuración ayuda a defenderse contra el clickjacking y otras vulnerabilidades de seguridad relacionadas con XSS.

Lo mejor es asegurarse de que todos los recursos que sirve la aplicación web siempre incluyan X-Frame-Options, con DENY en lugar de SAMEORIGIN. También debemos usar por defecto el máximo nivel de protección, ya que nunca podemos saber con certeza cuándo ni cómo podría salir el contenido de nuestra política de origen.

Encabezado Referrer-Policy

El encabezado Referrer-Policy controla la circulación de la información del referente de una aplicación o sitio web a otro. Contiene cuatro directivas principales —none, no-referrer, no-referrer-when-downgrade y origin— que determinan cómo comparte el navegador la URL de referencia con otros sitios o aplicaciones durante la navegación.

Podemos configurar este encabezado según nuestras necesidades para garantizar que los datos confidenciales no queden expuestos accidentalmente cuando los usuarios naveguen por varias propiedades web o dominios.

Lo ideal es establecer Referrer-Policy en no-referrer para que los encabezados de solicitud no incluyan información de referencia cuando los usuarios hagan clic en enlaces externos. Esta configuración protege su privacidad al evitar que se filtren datos personales por canales no previstos.

Cómo configurar encabezados de seguridad en JavaScript

En la siguiente sección se destacan tres herramientas que podemos usar para configurar encabezados de seguridad al desarrollar con JavaScript. Ten en cuenta que también puedes aplicarlas a otros lenguajes y ecosistemas.

Después de revisar cada herramienta, veremos un ejemplo práctico de cómo usarla para configurar encabezados de seguridad.

Helmet para Express.js

Helmet es una colección de encabezados de respuesta HTTP relacionados con la seguridad que ayudan a proteger las aplicaciones web contra ataques y vulnerabilidades. Helmet for Express.js es una extensión del paquete Helmet diseñada específicamente para funcionar con el framework Express.js. Proporciona nueve funciones de middleware más pequeñas que configuran encabezados de respuesta HTTP específicos relacionados con la seguridad para las aplicaciones.

Configurar Helmet para Express.js es sencillo. Primero, instala Helmet con este comando:

1npm install helmet

Luego, usa el siguiente código para requerir tanto el framework Express como el paquete Helmet y utilizar sus funciones de middleware. Así podremos configurar los encabezados de respuesta:

1const express = require("express");
2const helmet = require("helmet");

A continuación, usa este código para crear una instancia de una aplicación Express, asignarla a una variable y empezar a usar las funciones de middleware de Helmet:

1const app = express();
2app.use(helmet());

Al inicializar Helmet se configuran varios encabezados de seguridad, incluidos los cinco que vimos anteriormente. Podemos personalizar opciones específicas de los encabezados en Helmet para Express.js agregándolas al middleware helmet() con el siguiente código:

1app.use(
2  helmet({
3    X-Frame-Options: { policy: "DENY" },
4  })
5);

Helmet para Fastify

Helmet for Fastify es un paquete de middleware que permite agregar encabezados de seguridad importantes al framework web Fastify. Es, esencialmente, un wrapper de Helmet y acepta las mismas opciones.

Instala Helmet para Fastify ejecutando:

1npm i @fastify/helmet.

Luego, usa este código para requerir el framework Fastify y Helmet for Fastify:

1const fastify = require('fastify');
2const helmet = require('@fastify/helmet');

A continuación, registra el plugin Helmet en nuestra aplicación ejecutando este código:

1fastify.register(helmet);

Este comando configurará automáticamente los encabezados de seguridad básicos.

check-my-headers

Check-my-headers es una herramienta CLI gratuita que podemos usar para probar rápidamente los encabezados HTTP de nuestro sitio web y detectar posibles vulnerabilidades. Es gratuita y no depende de ningún framework; es decir, revisa nuestros encabezados sin importar qué usamos para configurarlos.

Podemos instalarla de forma global con npm install -g check-my-headers y ejecutar un análisis rápido introduciendo npx check-my-headers https://yourwebsite.com en la CLI.

Conclusión

Varios encabezados de respuesta HTTP clave influyen en la seguridad web, y aplicar las prácticas recomendadas para usarlos agrega una capa adicional de seguridad a las aplicaciones web. Los cinco encabezados que analizamos aquí ayudan a proteger contra diversas vulnerabilidades, como ataques CSRF, secuestro de sesiones, filtración de datos, ataques MITM y clickjacking, que pueden causar daños importantes y, a menudo, irreparables. Comprender cómo los encabezados de respuesta HTTP debilitan o contribuyen a la seguridad es un paso importante para mitigar estos vectores de ataque comunes.

Configurar y aprovechar correctamente los encabezados de respuesta es esencial para la seguridad web. Protegen la privacidad de los usuarios y ofrecen mayor flexibilidad para proteger la comunicación entre servidores web y clientes.