Volver |

Security Headers

Cuando un usuario envía una petición a un servidor web, el servidor responde con una respuesta HTTP. Esta respuesta, además de los datos, envía cabeceras que contienen metadata, reglas de caché, entre otras cosas. Dentro de estas cabeceras, hay varias especificas de seguridad. En este artículo se exponen las más populares y usadas.

Access-Control-Allow-Origin

Esta cabecera permite controlar el origen de un contenido.

Asumamos que tenemos un sitio A y un sitio B en donde A le intenta hacer peticiones a B.

Para permitir que A realice esas peticiones el sitio B debe especificar en esta cabecera que el sitio A es un sitio válido desde donde se pueden hacer peticiones.

AABBRequest httpDevuelve los datos con la cabecera Access-Control-Allow-Origin: http://www.sitio_a.com
Access-Control-Allow-Origin: http://www.sitio_a.com

Set-Cookie

Asegura que las cookies son enviadas por HTTPS, y que no son accesibles por Javascript. Vale aclarar que solo se pueden enviar cookies HTTPS si el sitio soporta HTTPS.

Es muy recomendable setear los flags Secure y HttpOnly.

La sintaxis de la cabecera es la siguiente:

Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Content-Security-Policy (CSP)

Esta cabecera se utiliza principalmente para ayudar a reducir el riesgo de ataques de cross site scripting (XSS). Consta de declarar qué recurso se permiten cargar en la página.

Todos los recursos que no se permitan en el CSP se bloquerarán y no se dejará que se ejecuten.

Por ejemplo, analicemos la siguiente cabecera:

Content-Security-Policy: default-src 'self'; img-src 'self' <https://www.nasa.gov/;> object-src 'none'; script-src 'self'; style-src 'self'; frame-ancestors 'self'; form-action 'self';
  • Por defecto, solo se permite contenido del sitio actual
  • Se permiten imágenes del sitio actual y de nasa.gov
  • No se permiten objetos como Flash o Java
  • Solo se permiten scripts del sitio actual
  • Solo se permiten estilos del sitio actual
  • Solo se permiten frames del sitio actual
  • Solo se permite enviar formularios al sitio actual

 

Strict-Transport-Security

Esta cabecera indica al navegador que el sitio debería ser accedido únicamente por HTTPS (siempre y cuando lo tenga habilitado). En el caso de usar subdominios, también se recomiendo forzar el uso.

Strict-Transport-Security: max-age=3600; includeSubDomains

X-XSS-Protection

Esta cabecera tiene el objetivo de detener ataques Cross Site Scripting en caso de detectar alguno. 
X-XSS-Protection: 1; mode=block

X-Content-Type-Options

Esta cabecera asegura que los MIME types definidos por la aplicación sea respetado por el navegador. Es útil para prevenir algunos ataques de XSS y también para prevenir comportamientos inesperados por parte del navegador cuando este intente suponer el tipo de contenido y lo hace incorrectamente.

El ataque más asociado a una mala configuración de esta cabecera es el MIME sniffing. El MIME sniffing, a grandes rasgos, consiste en que un atacante puede subir un archivo HTML malicioso (que contenga código para ejecutar un XSS) y cuando el navegador analice el archivo supondrá que el mismo parece código HTML por lo que lo ejecutará. Si la cabecera está bien definida, se evita este comportamiento.

X-Content-Type-Options: nosniff

Cache-Control

Esta cabecera permite definir si la página debe ser guardada en caché o no y bajo qué condiciones.

Cualquier página con datos sensibles debería configurar esta cabecera a no-cache. Con esto se evita que si en una computadora compartida, un usuario presiona el botón "volver atrás" o navega por el historial, no pueda ver información de otro usuario. En caso contrario, si esta cabecera no está configurada correctamente, el nuevo usuario podrá ver la información del otro ya que la misma se encuentra guardada en caché.

Sin embargo, existen páginas que no contienen datos sensibles y que no cambian frecuentemente como pueden ser los archivos estáticos (como imágenes, hojas de estilos, etc). En estos casos, el caché es una buena opción. Con esto en claro, debemos configurar en el servidor web qué archivos queremos guardar en caché y cuáles no

Ejemplo de configuración de caché (Apache):

# Por defecto no guarda caché de ningún archivo
Header set Cache-Control no-cache

# Configura caché por 1 día a los archivos cuya extensión sea: css, jpg, jpeg, png, gif, js e ico.
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$">
    Header set Cache-Control "max-age=86400, public"
</filesMatch>

Expires

Esta cabecera especifica hasta cuándo son válidos los archivos guardados en caché en la petición actual. Es ignorada si en la cabecera Cache-Control está configurado el max-age.

Para fines de seguridad, asumiremos que el navegador no debe hacer caché de nada por lo que la cabecera debería ser la siguiente:

Expires: 0

X-Frame-Options

Esta cabecera indica si el sitio permite estar embebido en un iFrame. Sirve particularmente para prevenir ataques de clickjacking. Sin esta cabecera correctamente configurada, un atacante podría cargar un iFrame en su sitio y establecer el sitio legítimo como fuente. Por ejemplo:

<iframe src="<https://dominiovictima.com>"></iframe>.

Existen tres valores posibles para esta cabecera:

  • DENY: Impide que la página del sitio se incluya en un iFrame. Es la mejor opción en caso de que el sitio no utilice iFrames.
  • SAMEORIGIN: Se permite incluir en un iFrame siempre y cuando sea desde el mismo origen.
  • ALLOW-FROM: Se especifica desde qué dominio puede inlcuirse el sitio dentro de un iFrame.
X-Frame-Options: deny

¿Dónde se configura?

Las cabeceras HTTP se especifican en el servidor web, por ejemplo en Apache o Nginx. Asimismo, si no se tiene acceso a la configuración del servidor web , se pueden especificar también desde el código.

Conclusión

Podemos concluir que configurar las cabeceras http es bastante simple y fácil pero sin embargo, nos proporcionan gran protección contra muchos de los ataques más comunes dentro de la seguridad web, por lo que es sumamente recomendable, tomarse el tiempo para definir correctamente las cabeceras a utilizar y configurarlas de la mejor manera.

Referencias

En este artículo participaron: