Response Headers en Netlify

Tomando en cuenta la seguridad de sitios estáticos.

Si no tiene fondo azul o al menos un candado, no es imagen de seguridad.

Debido a que Netlify nos provee de la encriptación del trafico, en conjunto al hosting, damos por hecho que ya partimos con una capa de seguridad, pero…

¿Es esa toda la seguridad que debemos utilizar?

Hace bastante tiempo había visto que en Netlify se podían definir HTTP response headers para “aumentar” el nivel de seguridad en tu sitio, debido a que con esto activas ciertas configuraciones que viene por defecto OFF, previniendo vulnerabilidades. De esta manera, defines un par de variables y automágicamente pasabas de “F” a “A” en sitios de rating.

Al meter mano en ENERGON, me propuse (al fin), en ver qué hacía cada uno de estos headers y si tenían algún impacto sobre el sitio (Analytics).

Si no utilizas la imagen de un encapuchado con un notebook, no estas hablando de seguridad.

Para evitar convertir este post en una guía rápida para subir la nota en un scan online, hablemos un poco sobre los HTTP Response Headers. Pero, si estás apurado, y solo necesitas la definición de los valores generales, ahí va:

[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
    X-XSS-Protection = "1; mode=block"
    Referrer-Policy = "no-referrer"
    X-Content-Type-Options = "nosniff"

Por cierto, hay bastante información y ejemplos sobre este tema, lo siguiente apunta a ser un resumen para tener una introducción amistosa.

💡 Mencionaré las cabeceras HTTP como headers, me incomoda demasiado decirles cabeceras.

HTTP Response Headers

Estos se manejan desde el fronén, en base a la definición de distintos tipos de Response Headers, que pueden activar varias funciones de seguridad en el navegador, que en su mayoría se encuentra desactivadas por defecto. Estas funciones pueden evitar ataques como XSS, Clickjacking y regalar una entrada a tu back-end.

Para mencionar las principales vulnerabilidades a tratar, me basé en la lista que utiliza el scan de SecurityHeaders. Estas son:

HTTP Strict Transport Security (HSTS): es una política de seguridad que fuerza el uso de TLS en los navegadores, para que solamente puedan establecer conexiones utilizando HTTPS.

• Config: Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Esta era la única habilitada por defecto.

Referrer Policy: es un header que nos permite saber sobre el visitante, por ejemplo, desde qué sitio viene. Por lo cual, la cantidad información entregada por este header, en el mejor de los casos debería ser limitada a lo necesario.

• Config: Referrer-policy = "no-referrer".
• Esta configuración evita incluir el referrer header por requests realizados desde tu sitio y sobre si mismo. Si tienes un team de Marketing que requiera analizar de dónde vienen sus usuarios, este no es un header que deberías utilizar.

X-Content-Type-Options: evita que el navegador realice un MIME-sniff, el cual determina el formato de un archivo en base a su contenido, lo que puede ser explotado para realizar un XSS. Permitiendo por ejemplo, subir un .html como un .jpg para que el MIME-sniff lo modifique al formato correspondiente.

• Config: X-Content-Type-Options = "nosniff". Esta config solo posee como valor válido el “nosniff”.

X-Frame-Options: un iframe es utilizado para mostrar una pagina sobre otra pagina web, lo cual facilita ataques como clickjacking. La forma para evitar que esto ocurra es especificando que tu sitio, no pueda ser utilizado por frames.

• Config: X-Frame-Options: DENY

X-XSS-Protection: define la configuración para evitar el cross-site scripting desde navegadores.

• Config: X-XSS-Protection: 0; mode=block.
• Aquí un lindo ejemplo.

Content Security Policy (CSP): similar a HSTS, permite definir los contenido aprobado que se carga en el navegador (fonts, Analytics, parrots).

• Config: como son bastantes las fuentes que puedes aprobar para que el navegador cargue el contenido, dejo un link especificando las definiciones.
• El ejemplo que se entrega en el link de CSP, menciona como se puede subir un XSS dentro de un comentario. Al acceder al sitio desde otro navegador, el comentario en conjunto al resto de los contenidos de la página serán cargados.

Feature Policy: permite habilitar y controlar el uso de APIs en el navegador. Mediante la definición de dónde o cómo deben ser llamadas estas características del sitio.

• Config: Feature-Policy: FEATURE 'self'; FEATURE2 '*'; FEATURE3 'energon.cloud'.

Ahora que sabemos porque debemos debemos considerar el uso de Response Headers, podemos revisar nuestro sitio, pero sin scan aún.

💡 Tienes que merecerte el scan, entendiendo lo que este hace y así podrás valorar su sistema de calificación.

Revisión manual

Sin scan aún, para ver los Response Headers de un sitio, puedes hacerlo desde tu navegador. Desde Chrome, vendría siendo lo siguiente:

Click derecho para abrir Inspect > Network > recargar la página > revisar un Request es especifico.

Safari.

El sitio de ENERGON, ya tiene definidos los Headers, por lo tanto aquí va uno sin las definiciones correspondientes:

So insecure less headers wow

Una forma mucho mas rápida y limpia, es con el siguiente CURL:

curl -sSL -D - energon.cloud -o /dev/null

Este solo muestra la información de los Headers, descartando el resto. Ahora que sabemos cómo ver los Response Headers manualmente, merecemos el poder utilizar Scanners, pero: ¿por qué usar uno?

Scan online

Hay varios tipos, colores, tamaños y funciones. Estos sirven como punto referencia para análisis de vulnerabilidades según se necesite, pero como en este caso estamos analizando los HTTP Response Headers, requerimos de uno que este orientado a tal tarea.

¿Qué hacen de distinto?

Mi primer referente sobre scan de Headers fue en base a este post, donde se hacía el análisis en base a Security Headers. Si bien, mostraba la solución, no mostraba el proceso para llegar a esa conclusión (a mi gusto).

De eso me surgía la duda: ¿qué estoy resolviendo?

Volviendo al scan, realiza el mismo procedimiento manual e incluye las posibles medidas a tomar y de paso utilizan un lindo sistema de calificación para hacerte sentir mal.

Otros scans de Headers destacables:

• Hackertarget — Es como un CURL, pero online.

Security Headers

Para hacer el scan, debes ir a su sitio, poner el dominio que quieres scannear y ya.

El salón de la vergüenza es un bonito detalle.

¿Qué analiza?

Evalúa los HTTP response headers mencionados al principio, del sitio scanneado, agregándole un sistema de valoración. Lo cual nos entrega el siguiente resultado:

Al menos no es una “F”.

Bien, ahora que tenemos eso claro, solo tenemos que definir esa configuración de los headers y así, dormir con la consciencia tranquila.

¿Cómo puedo definir eso en Netlify?

La mayoría de hostings para sitios estáticos, proveen una forma para definir los headers. En Netlify esto es logrado mediante el netlify.toml que va en el mismo path que tu index.html.

Pese a que puedes definirlo como un _headers, recomiendo utilizar el netlify.toml ya que en conjunto a otras definiciones como build-steps y tests, queda mas ordenado.

Mirando la documentación rápidamente podemos ver las siguientes definiciones para el archivo _headers:

• Reglas para una o más URLs:

## A path:
/templates/index.html
  # Headers for that path:
  X-Frame-Options: DENY
  X-XSS-Protection: 1; mode=block
/templates/index2.html
  X-Frame-Options: SAMEORIGIN

• Reglas para todas las páginas del sitio:

/*   
  X-Frame-Options: DENY
  X-XSS-Protection: 1; mode=block

Puedes validar las reglas de tu _headers, colocando lo siguiente en el playground de Netlify:

/*
 X-Frame-Options: DENY
 X-XSS-Protection: 1; mode=block
 Referrer-Policy: no-referrer
 X-Content-Type-Options: nosniff

De ser válidas, te entregará como resultado el formato para netlify.toml:

[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
    X-XSS-Protection = "1; mode=block"
    Referrer-Policy = "no-referrer"
    X-Content-Type-Options = "nosniff"

Para más información sobre headers en Netlify, aquí.

Felicidades, ahora sabes sobre seguridad, seguridad de HTTP Response Headers.

En resumen

• Si tuvieras una página HTML simple, con fondo blanco y texto, no es necesario preocuparte de un XSS, por mas que el escáner te ponga una mala nota.
• Si alguno de esos HTTP Response Headers menciona alguna característica explotable de tu sitio, realiza la configuración correcta para activarlos.
• Al definir Referrer-Policy = "no-referrer", usando Google Analytics. No sacarás mucho provecho, ya que no tendrás el punto de referencia desde donde estos llegan a tu sitio. Pista: "strict-origin" o "strict-origin-when-crossorigin"

Links relevantes:

• How I Increased the Security of My Netlify Hosted Website With This One Small Trick! Hackers HATE It! — Ese es un título.
• Security for Static Websites — Excelente post.
• Should you implement the meta referrer tag? — Para ayudarte a decidir sobre que te conviene mas para tus Analytics.
• The meta referrer tag — Buen punto de referencia para leer brevemente como trabaja el tag referrer.
• What is my Referer? — Si le das click, te mostrará de donde vienes 🔮.

Agradecimientos a Pedro Leiva Tagle por el feedback de seguridad y a csslab por el de Netlify.