¿Por qué son tan importantes los header HTTP?

La norma ISO 27001:2002 en su control 8.25 indica que el ciclo de vida de desarrollo del software debe ser seguro. Este ciclo de vida (Software Development Life Cycle, SDLC por sus siglas en inglés) aborda las fases de gestión de requerimientos, diseño de soluciones, desarrollo, pruebas y despliegue. A continuación, este artículo detalla únicamente las configuraciones mínimas que deben ser consideradas durante la fase de desarrollo, para lograr aplicaciones web seguras. Otros controles de seguridad relacionados con el SDLC pueden consultarse aquí.

¿Qué es HTTP?

HTTP (Hypertext Transfer Protocol) es un protocolo de red de la capa de aplicación del modelo OSI y que requiere de una conexión TCP/IP para funcionar. Es la piedra angular de las comunicaciones entre buscadores web clientes y servidores web. Existen alternativas para comunicación entre clientes y servidores en la capa de aplicación del modelo OSI, como WebRTC (Solo para multimedia) o QUIC; sin embargo, no son tan populares ni tan comúnmente usados como HTTP.

HTTP es un protocolo “stateless” lo que significa que cada interacción entre el cliente y el servidor es única y no depende de interacciones anteriores. Por tanto, una sesión HTTP no es persistente en sí misma (aunque una sesión TCP sí lo es) y los desarrolladores dependen de otras herramientas, como las cookies, para mantener sesiones HTTP persistentes entre clientes y servidores. Actualmente, HTTP funciona en la versión 2, que permite intercambiar más de un archivo o dato en cada sesión TCP. En el futuro, se espera que HTTP y QUIC confluyan en HTTP 3.

¿Qué vulnerabilidades de seguridad de TI aprovechan HTTP?

En general, algunas vulnerabilidades de la capa de aplicación del modelo OSI son vulnerabilidades que aprovechan HTTP, pero no todas. Las vulnerabilidades de capa de aplicación están ampliamente detalladas en el top 10 OWASP 2021, pueden ser clasificadas como vulnerabilidades que aprovechan o requieren HTTP y vulnerabilidades que no necesariamente necesitan HTTP:

Vulnerabilidades Top 10 OWASP 2021 que aprovechan HTTP

• A01: Fallos de control de acceso.
• A03: Inyección.
• A05: Fallos de configuraciones de seguridad.
• A06: Componentes vulnerables o desactualizados.
• A07: Fallos de identificación y autenticación
• A10: Server Side Request Forgery

Vulnerabilidades Top 10 OWASP 2021 que no necesariamente aprovechan HTTP

• A02: Fallos Criptográficos.
• A04: Diseño Inseguro.
• A08: Fallos de integridad de software y datos.
• A09: Fallos de registro de logs y monitoreo de seguridad

¿Qué puede hacer un desarrollador para reducir el impacto de las vulnerabilidades en sesiones HTTP?

Además de los datos útiles (payload), una conexión HTTP permite el intercambio de otros datos entre el cliente y el servidor, para parametrizar esta conexión. A cada uno de estos parámetros se le conoce como un HTTP header. Algunos de estos header se deben configurar con valores específicos para establecer una conexión HTTP segura entre el cliente y el servidor, ya que HTTP no es seguro por defecto. Algunos header importantes son:

• Conexiones HTTP cifradas (HTTPS)
• HTTP headers de seguridad (E.g. Content Security Policies)

En adición, al hacer una implementación insegura de HTTP, se deben considerar algunas medidas diferentes a los HTTP header como:

• Seguridad en Cookies
• Componentes de software actualizados
• Web Application Firewalls (WAFs)

A continuación, más información sobre estas medidas.

Conexiones HTTP cifradas (HTTPS)

El efecto de no aplicar las siguientes configuraciones es que la conexión entre un usuario y un servidor (por ejemplo, credenciales de sesión, datos personales, datos confidenciales) será interceptada en el medio y vista por terceros no autorizados (por ejemplo, atacantes).

• Certificado de seguridad TLS

Un certificado de seguridad TLS no opera en la capa de aplicación del modelo OSI (donde opera HTTP), sino en la capa de transporte, por lo que puede considerarse como un prerrequisito para establecer una comunicación HTTP. De hecho, TLS significa (Transport Layer Security) Seguridad en la capa de transporte. Es un protocolo que aprovecha la criptografía de infraestructura pública para cifrar una conexión TCP entre un cliente y un servidor. AWS ofrece un servicio propio para generar certificados TLS que se puedan utilizar en aplicaciones creadas en la nube, llamado AWS Certificate Manager.

Al requerir un certificado público, una aplicación puede estar expuesta a internet y requerir conexiones TLS seguras.

Para que una aplicación pueda salir a internet, el FQDN de la aplicación debe ser expuesto a través de un DNS público, como AWS Route 53

La versión de TLS más actualizada es 1.3, aunque las conexiones de la versión 1.2 aún se consideran seguras. Cualquier versión anterior a estas, ya no es considerada como segura.

• Strict-Transport-Security (HSTS)

Ya en la capa de aplicación del modelo OSI y dentro del protocolo HTTP, la primera medida de seguridad para cifrar las comunicaciones entre el cliente y el servidor es el uso del HTTP header Strict-Transport-Security (HSTS). Este HTTP header, al igual que los demás headers, se configura en el framework de front end que la aplicación esté utilizando. Para este artículo se ha tomado como referencia node.js.

El HTTP header Strict-Transport-Security (HSTS) rechaza cualquier conexión entre un cliente y un servidor que no esté mediada por TLS, luego este header obliga a que el certificado de seguridad TLS exista en el servidor, para poder establecer una comunicación con un cliente. En node.js se configura añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación)

app.use(function(req, res, next) {
 if (req.secure) {
   res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
 }
next();
})

    
En este caso, el parámetro “Strict-Transport-Security” obliga a que la conexión entre el cliente y el servidor utilice un certificado TLS válido y el parámetro “max-age”, fijado en milisegundos, fija el tiempo máximo para una conexión HTTP.

El resultado esperado es de aplicar estas configuraciones, es que todas las conexiones al servidor usarán una URL de la forma http[s]://www.dominio.extension y se rechazará cualquier otro tipo de conexión no cifrada en transporte. Es fundamental aplicar estas configuraciones para proteger los datos de los usuarios de una aplicación de la intercepción no autorizada.

HTTP headers de seguridad

Los HTTP headers de seguridad sirven para implementar configuraciones destinadas a reducir significativamente la probabilidad de ciberataques en aplicaciones expuestas a internet. A continuación, los HTTP headers de seguridad más comunes.

• Cross-Origin-Embedder-Policy (COEP)

Este HTTP header permite o deniega la característica de embeber o cargar archivos en la aplicación. Si se configura como “require-corp” sólo se podrán cargar archivos desde el mismo backend y habrá que configurar permisos individuales para cada archivo que se vaya a compartir. Ésta, a pesar de ser una configuración segura, no es flexible. Se recomienda usar “credentialless”, ya que permite cargar documentos de otros orígenes, como páginas web de terceros, pero elimina los metadatos del origen como las cookies, lo que sigue siendo seguro. En ningún caso se recomienda dejar este HTTP header por defecto o en la configuración “unsafe-none” ya que es inseguro al permitir que terceros introduzcan cookies o código malicioso en una página web a través de archivos. En node.js se configura añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación).

app.use((req, res, next) => {
 res.setHeader('Cross-Origin-Embedder-Policy', 'credentialless');
 next();
});

• Cross-Origin-Opener-Policy (COOP)

Este HTTP header protege a la aplicación de que la acción de abrir una ventana o pop-up pueda utilizarse para inyectar código malicioso o redirigir a un sitio malicioso. La configuración “unsafe-none” es la configuración predeterminada que permite que la aplicación cargue cualquier archivo o página (incluyendo los maliciosos) en la acción de ventana emergente. Para conseguir un equilibrio entre seguridad y usabilidad se recomienda usar la configuración “same-origin-allow-popups”, que permite cargar cualquier archivo o página del mismo origen que la aplicación. Las configuraciones “same-origin” y “noopener-allow-popups” requieren configuración individual de cada iframe o documento que aparezca en el pop-up, por lo que no son prácticas.

En node.js se configura añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación)

app.use((req, res, next) => {
 res.setHeader('Cross-Origin-Opener-Policy', 'same-origin-allow-popups');
 res.setHeader('Cross-Origin-Resource-Policy', 'cross-origin');
 next();
});

• Cross-Origin-Resource-Policy (CORP)

Este HTTP header controla qué aplicaciones de terceros pueden usar partes de la aplicación desarrollada como pop-ups o referenciar archivos expuestos a internet por la aplicación desarrollada. Este control es útil para evitar, por     ejemplo,suplantaciones de la aplicación. En este sentido, se recomienda usar la configuración “same-origin” que sólo permite a aplicaciones que compartan el mismo backend o URL usar archivos de la aplicación desarrollada. La configuración “same-site” ya no se considera segura y la configuración “cross-origin” permite eventualmente que terceros obtengan archivos de la aplicación desarrollada.

En node.js se configura añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación)

app.use((req, res, next) => {
 res.setHeader('Cross-Origin-Resource-Policy', 'same-origin');
 next();
});

• Content-Security-Policy (CSP)

Este HTTP header es uno de los más importantes y no debería ser ignorado en ninguna aplicación que deba considerarse segura. Sirve para controlar cuáles son los archivos, scripts, imágenes y otros documentos que pueden intervenir en una comunicación HTTP entre un cliente y un servidor. Esto es fundamental para evitar los ataques del tipo Cross Site Scripting y Server Side Request Forgery. Las configuraciones (o directivas) de la CSP son:

• default-src: Indica cuál es la fuente de los archivos que se cargan en la página. Su configuración por defecto es “*”, lo cual es inseguro ya que permite cualquier tipo de fuente para los archivos que carga la página. La configuración recomendada es dejarla en “self” para cargar archivos del mismo servidor o escribir el listado de URL de terceros de las cuales la aplicación consume recursos.
• script-src: Indica qué scripts se deben ejecutar en el frontend. La configuración “unsafe-inline” se considera insegura ya que permite la eventual inyección de scripts no autorizados, mientras que la configuración recomendada es “self” para ejecutar scripts del mismo servidor.
• style-src: Controla el origen de los estilos CSS de la aplicación. La configuración “unsafe-inline” se considera insegura ya que permite la eventual inyección de scripts no autorizados, mientras que la configuración recomendada es “self” para renderizar fuentes almacenadas en el mismo servidor. También se puede complementar listando las URL de terceros de dónde provengan las fuentes utilizadas en la aplicación.
• img-src: Controla las imágenes utilizadas en la aplicación. La configuración “unsafe-inline” se considera insegura ya que permite la eventual inyección de scripts no autorizados, mientras que la configuración recomendada es “self” para mostrar imágenes almacenadas en el mismo servidor. También se puede complementar listando las URL de terceros de dónde provengan las imágenes utilizadas en la aplicación.
• font-src: Controla las fuentes de letra de la aplicación. La configuración “unsafe-inline” se considera insegura ya que permite la eventual inyección de scripts no autorizados, mientras que la configuración recomendada es “self” para renderizar fuentes almacenadas en el mismo servidor. También se puede complementar listando las URL de terceros de dónde provengan las fuentes utilizadas en la aplicación.
• Object-src: Bloquea la eventual ejecución de tipos legados de objetos de aplicación, como applet. Su configuración recomendada es “none”.
• Frame-ancestors: Controla qué sitios de terceros pueden exponer contenidos de la aplicación como iframe. Su configuración recomendada es “none”, a menos que esta función sea requerida, cuyo caso, la configuración recomendada es listar las URL de los sitios de terceros que pueden exponer partes de la aplicación como iframe.

En node.js, las CSP se configuran añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación)

app.use((req, res, next) => {
 res.setHeader('Content-Security-Policy', 
   `default-src 'self'; ` +
   `script-src 'self'; ` +
   `style-src 'self'; ` +
   `img-src 'self' data:; ` +
   `font-src 'self' https://legit.fonts.com; ` +
   `object-src 'none'; ` +
   `frame-ancestors 'none'`
 );
 next();
});

• X-Content-Type-Options

Este HTTP header obliga a los navegadores web del lado del cliente a no modificar los Content-Type definidos por la aplicación y no realizar escaneos (sniffing) basado en MIME. Esta configuración es muy útil para limitar el impacto de las tareas de reconocimiento que se ejecutan antes del inicio de un ciberataque.

En node.js se configura añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación)

app.use((req, res, next) => {
 res.setHeader('X-Content-Type-Options', 'nosniff');
 next();
});

• X-Frame-Options (XFO)

Esta configuración complementa la HTTP header “Cross-Origin-Resource-Policy (CORP)”. También debe habilitarse y es eficaz para evitar que terceros no autorizados utilicen los archivos de la aplicación. Su valores son “DENY”, el cual deniega cualquier uso de los archivos de la aplicación, o “SAMEORIGIN” que permite que las aplicaciones que compartan el mismo backend o URL usen archivos de la aplicación desarrollada.

En node.js se configura añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación)

app.use((req, res, next) => {
 res.setHeader('X-Frame-Options', 'SAMEORIGIN');
 next();
});

Seguridad en cookies

Las cookies son datos que el navegador web almacena del lado del cliente para mantener una sesión HTTP con un servidor. Al igual que los HTTP header, las cookies deben ser configuradas para que en el caso eventual de ser robadas o divulgadas, no puedan ser usadas para suplantar una sesión HTTP legítima. Las cuatro configuraciones que se deben implementar, son las siguientes:

• HTTP Only: Su valor siempre debe ser “True” y sirve para complementar el HTTP header “Strict-Transport-Security (HSTS)”
• Secure: Al igual que la configuración anterior, Su valor siempre debe ser “True” y sirve para complementar el HTTP header “Strict-Transport-Security (HSTS)”.
• sameSite:  Su valor siempre debe ser “Strict” y sirve para complementar los HTTP header de “Content-Security-Policy (CSP)”.
• maxAge: Indica cuándo la cookie deja de ser válida y se requiere una sesión HTTP completamente nueva entre el cliente y el servidor, para crear una nueva cookie. Su valor es numérico y expresa, en milisegundos, durante cuánto tiempo debe ser válida una cookie. Su valor recomendado es de 1 hora.

En node.js se configura usando el framework express y añadiendo la siguiente porción de código al archivo que inicia el servidor (app.js o server.js según la implementación) para hacer que una cookie sea segura:

const express = require('express');
const cookieParser = require('cookie-parser');
const app = express();
app.use(cookieParser());
// Trust proxy if behind a load balancer (e.g., Heroku, Nginx)
app.set('trust proxy', 1);
app.get('/set-cookie', (req, res) => {
 res.cookie('session_id', 'your-session-token', {
   httpOnly: true,        
   secure: true,        
   sameSite: 'Strict',    
   maxAge: 60 * 60 * 1000 
 });
 res.send('Secure cookie set');
});
app.listen(3000, () => {
 console.log('Server running on https://localhost:3000');
});

Componentes de software actualizados

Existen diferentes tipos de software que se utilizan tanto del lado del cliente como del servidor para mantener una sesión HTTP de una aplicación web. Todos estos componentes deben utilizarse en sus versiones más recientes, para evitar vulnerabilidades que permitan hacer eludir a las configuraciones HTTP y de cookies anteriormente mencionadas.

Componentes de software en el cliente

• Buscadores web
• Sistema operativo
• Antimalware
• Web Security Gateway
• VPN

Componentes de software en el servidor

• Sistema Operativo
• Servidor de aplicación
• Antimalware
• Firewall
• WAF
   

Web Application Firewalls (WAFs)

Un WAF es un control técnico que filtra las conexiones HTTP que recibe un servidor. A diferencia de un firewall tradicional, un WAF cuenta con herramientas especializadas para detectar la inyección de código malicioso en el intercambio de información HTTP. Por ejemplo, AWS permite implementar un WAF “de caja” con baja configuración por un costo cercano a los USD 30 / Mes. En otros artículos se profundizará en el funcionamiento y la configuración de un WAF.

Conclusión

Para cumplir con el control A 8.25 de la norma ISO 27001:2022 se requieren medidas de seguridad durante todo el ciclo de vida del desarrollo de software (SDLC), que comprende la gestión de requerimientos, el diseño de soluciones, el desarrollo, prueba y el despliegue de aplicaciones. Específicamente, para el desarrollo de aplicaciones web, existen 5 medidas que se deben implementar en todos los desarrollos: Conexiones HTTP cifradas (HTTPS), HTTP headers de seguridad (E.g. Content Security Policies), Seguridad en Cookies, Componentes de software actualizados y Web Application Firewalls (WAFs).

Con estas medidas, una aplicación web estará disponible de forma segura en Internet, en un entorno donde cada día se vulneran los datos de cientos de aplicaciones y se alimenta una industria criminal que puede destruir no solo los bolsillos, sino también la reputación de las empresas y sus desarrolladores de software.