Para mantener a salvo y seguras las páginas web y aplicaciones online, desarrolladores y administradores de sistemas se centran en mantener actualizados los componentes del servidor, actualizar plugins y el núcleo del gestor de contenidos, frameworks, librerías externas, establecer una política de backups y de recuperación de datos, disponer de un certificado SSL… Pero muy pocos se centran en los encabezados HTTP.
Existen determinados encabezados HTTP que correctamente configurados, ayudarán a mejorar la seguridad. Previenen determinados tipos de ataques o consiguen atenuar sus consecuencias, poniéndoselo más difícil a los atacantes.
Evaluar la seguridad HTTP de tu web o aplicación
Antes de mencionar como mejorar la seguridad mediante encabezados HTTP conviene saber el estado de tu web. Quizás tu desarrollador o proveedor de alojamiento haya tenido esto en cuenta y tenga implementada una buena política de encabezados HTTP.
Para validar esto te recomiendo acudas al Mozilla Observatory, donde podrás introducir el nombre de tu dominio. Obtendrás un informe con el grado de seguridad y protección de tu web, analizando aspectos como el tipo de certificado SSL instalado y la configuración de encabezados HTTP.
Pulsando en el nombre de cada uno de los test ejecutados en tu dominio tendrás una descripción de la política y notas sobre una buena implementación, con ejemplos en algunos casos.
Si no has obtenido una buena puntuación en el test, sigue leyendo para ver como configurar los encabezados más típicos o contacta con tu proveedor o desarrollador para que lleve a cabo esta tarea.
Cabeceras de seguridad HTTP a considerar
Vamos a mencionar los encabezados más típicos y sencillos de configurar. Hacerlo no lleva más de unos pocos minutos y conseguirás mejorar la protección de tu web o aplicación online.
Se implementan modificando el fichero de configuración del servidor web. Pondremos ejemplos para Apache y Nginx, los 2 servidores web más empleados en la actualidad para la mayoría de gestores de contenidos, como Wordpress.
En Apache la configuración se aplica editando el fichero .htaccess en la raíz del sitio web. En Nginx el fichero de configuración suele denominarse nginx.conf. Algunos servidores disponen de un panel como Plesk o Cpanel desde los que poder aplicar estas directivas de configuración directamente a un dominio.
Veamos las cabeceras de seguridad HTTP más fáciles de configurar y útiles para tu proyecto web.
X-Frame-Options
Esta cabecera previene los ataques de tipo clickjacking, una técnica maliciosa basada en insertar tu página, mediante iframe, en otra aparentemente normal. Si el usuario tiene la sesión iniciada en tu web, el atacante podría hacerse con información sensible de la cuenta del usuario.
Enviando este encabezado HTTP podremos controlar si permitimos o no cargar nuestro sitio web en iframes. Las opciones disponibles son:
- DENY: impide cargar tu web en cualquier iframe.
- SAMEORIGIN: sólo se permite poner en iframe contenidos desde el propio dominio.
- ALLOW-FROM: para especificar una lista de dominios con derecho a crear iframe de nuestros contenidos, el resto serán bloqueados.
Implementar X-Frame-Options en Apache
<IfModule mod_headers.c> Header always append X-Frame-Options SAMEORIGIN </IfModule>Implementar X-Frame-Options en Nginx
add_header X-Frame-Options "SAMEORIGIN" always;X-XSS-Protection
Previene de ataques XSS (cross-site scripting), una posible vulnerabilidad que permitirá a un atacante ejecutar código JavaScript (o similar), con el que podría robar información o secuestrar sesiones de usuario.
Empleando adecuadamente el encabezado Content Security Policy, que veremos más adelante, podríamos prevenir este tipo de ataques, pero aun así es conveniente establecer este encabezado con el valor 1; mode=block para estar protegidos.
Implementar X-XSS-Protection en Apache
<IfModule mod_headers.c> Header set X-XSS-Protection "1; mode=block" </IfModule>Implementar X-Frame-Options en Nginx
add_header X-XSS-Protection "1; mode=block" always;X-Content-Type-Options
Sirve para indicar al navegador web que no cargue o interprete ficheros cuyo tipo de contenido (tipo MIME) no haya sido correctamente establecido por el servidor. Sin esto, un navegador podría detectar incorrectamente un fichero como un fichero de script (Javascript) o de estilos CSS, y dar pie a ataques de tipo XSS.
La opción más habitual para esta cabecera es nosniff.
Implementar X-Content-Type-Options en Apache
<IfModule mod_headers.c> Header set X-Content-Type-Options nosniff </IfModule>Implementar X-Content-Type-Options en Nginx
add_header X-Content-Type-Options "nosniff" always;HSTS (HTTP Strict Transport Security)
Fuerza al navegador del cliente a emplear únicamente conexiones HTTPS, aunque se especifique http:// al acceder a una URL.
Esta cabecera permite indicar:
- max-age: el tiempo en segundos durante el cual se harán redirecciones al protocolo HTTPS. El valor mínimo debe ser de 6 meses (15768000), aunque se recomienda establecer un periodo de 2 años (63072000).
- includeSubDomains: si aplicar los efectos a todos los subdominios del dominio principal.
Implementar HSTS en Apache
<VirtualHost 178.33.167.244:443> Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains" </VirtualHost>Donde deberás sustituir 178.33.167.244 por la IP de tu servidor o la asociada a tu dominio.
Implementar HSTS en Nginx
add_header Strict-Transport-Security max-age=15768000;Content-Security-Policy (CSP)
Ofrece un montón de posibilidades de configuración. Nos permite establecer y restringir los orígenes desde los que poder cargar o recuperar determinados tipos de contenidos específicos, como imágenes, ficheros de estilos CSS, ficheros de script, llamadas y peticiones AJAX…
Es una directiva soportada por los navegadores modernos, y constituye la herramienta más eficaz para reducir riesgos de ataques XSS y clickjacking.
Podemos especificar opciones y orígenes para una gran cantidad de tipos de contenidos. Las más habituales son:
- script-src: fuentes JavaScript legítimas.
- img-src: fuentes de ficheros de imágenes.
- style-src: fuentes de ficheros de estilo CSS.
- font-src: para tipos de letra (fuentes).
- connect-src: se aplica a conexiones WebSocket, XMLHttpRequest (Ajax) y EventSource.
- default-src: para definir la política estándar de cualquier tipo de conexión y fuentes de contenido.
A estas directivas podemos indicar ciertas palabras clave que hacen referencia a fuentes especiales de contenido:
- none: ninguna URL coincidente.
- self: la propia URL del dominio.
- unsafe-inline: permite uso de código javascript inline.
- unsafe-eval: permite la función eval() para generar código javascript interpretable desde cadenas de texto.
Por ejemplo, podemos deshabilitar el código inline y forzar conexiones https usando: default-src https:
Limitar la carga de ficheros de script al propio dominio con: script-src 'self'
Permitir la carga de imágenes desde el propio dominio y de algún lugar como un CDN, por ejemplo: img-src 'self' cdn.example.com
No hay una configuración estándar que funcione para cada sitio o proyecto web, pues dependerá de si se usa CDN o no, si se cargan fuentes de texto desde Google Fonts u otro origen, etc.
Habrá que determinar de qué orígenes y fuentes tomamos contenidos, e interactuamos, para establecer una política restrictiva oportuna que no afecte al normal funcionamiento de nuestro proyecto.
Un caso típico es el siguiente, en el que sólo se permite la carga de ficheros de imágenes, estilos y scripts desde el propio dominio.
Implementar Content-Security-Policy en Apache
<IfModule mod_headers.c> Header set Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';" </IfModule>Implementar Content-Security-Policy en Nginx
add_header Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';";En conclusión
Hay cabeceras HTTP diseñadas para dar un extra en seguridad a nuestro proyecto web, proteger la información de nuestros usuarios y la integridad del sitio en sí.
No siempre se presta atención a este aspecto. Pero como hemos visto, de una forma muy rápida puede añadirse un nivel de seguridad extra añadiendo unas pocas líneas de configuración al servidor web.
Existen más encabezados HTTP relacionados con la seguridad. Las últimas versiones de los servidores web ya incorporan algunas políticas por defecto, y seguramente sólo haya que prestar atención a las mencionadas en este artículo.
Herramientas como el Mozilla Observatory nos dan un resumen muy acertado e indicará que políticas, directivas y encabezados faltan por incorporar.
Ilustración principal cortesía de stories – freepik.es
