Pon un "Referrer Policy" y mejora la seguridad de tu web

Una de las opciones que se puede configurar a nivel de hipervínculo, de documento o de servidor web en los navegadores es el funcionamiento de la política para el HTTP Header "Referrer", para mejorar la seguridad de una aplicación web. Para entender en qué consiste esta política, primero hay que hacer un pequeño resumen de cómo funciona el campo HTTP Referrer que se envía desde los navegadores que cada vez que se hace clic en un hipervínculo de un documento HTML.

Figura 1: Pon una "Referrer Policy" y mejora la seguridad de tu aplicación web

La idea es que cuando se llega a un sitio al que llamaremos URI_destino, a través de hacer un clic en un enlace en un sitio al que llamaremos URI_origen, el navegador envía una cabecera HTTP al servidor URI_destino que se identifica como "Referrer" y donde se encuentra la dirección absoluta o relativa del URI_origen donde estaba el enlace que le llevó al lugar en que el navegador está ahora.

Figura 2: IETF RFC 7231 sección Referrer Header

Esto puede ser muy útil o muy peligroso si no se controla, ya que se podrían enviar direcciones internas de sistemas privados, o direcciones URL de aplicaciones privilegiadas que necesitan de unas credenciales para entrar a sitios no deseados. El uso de esta cabecera no se creo pensando en los posibles riesgos de seguridad, sino como se recoge en el RFC del IETF, para que los administradores de los sitios pudieran hacer estadísticas, crear backlinks, etc...

Figura 3: Campo Referrer enviado desde el cliente con una URL completa

Sin embargo, tiene una fuerte implicación en la seguridad, y alguien podría plantear un ataque de CSRF (Cross-Site Request Forgery), XSPA (Cross-Site Port Attack), o simplemente de phishing, a través de las direcciones URL que quedaran filtradas en las cabeceras HTTP Referrer que envían los navegadores de Internet. Para mitigar esta problemática existen varias configuraciones distintas.

Políticas Referrer: Configuraciones

Como se puede ver a continuación, se pueden establecer diferentes políticas de seguridad para evitar que la URL con los parámetros y sus valores - donde pueden filtrarse nombres de usuarios, directorios privados, cookies de sesión o información sensible de una organización - acaben en las estadísticas de un sitio remoto o en las manos de un tercero. Los valores que pueden configurarse en las políticas Referrer son los siguientes, y cada uno forzará un comportamiento diferente en el navegador.

- no-referrer: En este caso, no se enviará nunca el HTTP Header Referrer desde el cliente. 

- no-referrer-when-downgrade: Este es el valor por defecto en muchos navegadores y consiste en que se envía Referrer con la URL de la web si el destino es igual o más seguro. Es decir,  se envía cuando el hipervínculo va de una página HTTP a una página HTTP, cuando va de una página HTTP  a una página HTTPs y cuando va de una página HTTPs a una página HTTPs, pero no cuando va de una página HTTPs a una página HTTP.

Figura 4: Ejemplos no-referrer-when-downgrade en Mozilla

- origin: Con este modificador, el valor Referrer que se envía no especificará la dirección URL completa, y solo llevará en nombre del dominio y el protocolo. Es decir, se elimina el Path de la dirección URL de origen del hipervínculo. 

Figura 5: Ejemplo con valor origin

- origin-when-cross-origin: En este caso, cuando el hipervínculo es dentro del mismo dominio, se envía la URL completa, y cuando el hipervínculo es a otro origen, se envía entonces solo el dominio y el protocolo de la URL, sin el Path.

Figura 6: Ejemplos de origin-when-cross-origin

- same-origin: Con este valor, el HTTP header Referrer se enviará cuando el hipervínculo sea dentro del mismo dominio y no se enviará cuando sea entre distintos dominios.

Figura 7: Ejemplos con same-origin

- strict-origin: Solo se envía en el Referrer el origen del hipervínculo (solo el dominio y el protocolo de la URL sin el path) a un destino más seguro. Nunca en un hipervínculo HTTPs-HTTP.

Figura 8: Ejemplos con strict-origin

- strict-origin-when-cross-origin: Se envía en Referrer la URL completa a un destino dentro del mismo dominio más seguro, y solo el dominio y el puerto a un destino igual o más seguro, pero nada a un destino menos seguro.

Figura 9: Ejemplos con strict-origin-when-cross-origin

- unsafe-URL: En este caso, se envía la URL completa a cualquier destino pero sin valores en los parámetros de la URL (para evitar el envío de nombres de usuarios, cookies de sesión o información sensible).

Políticas Referrer: Establecimiento de política

La primera forma de configurar el comportamiento del navegador con los campos Referrer es a nivel de documento HTML con el uso de una META Tag llamada Referrer donde se establece una política para todos los hipervínculos que se generen - tanto de forma estática como de forma dinámica - desde esa URL.

Figura 10: Algunos valores de la Meta Tag "referrer" en HTML

Añadir un código Javascript que configure la política de tu aplicación web que tú quieras sería algo como lo que tienes en la imagen siguiente, y te permitiría automatizarlo en todas las webs si lo introduces en alguna de las librerías que uses siempre.

Figura 11: Configuración de Meta Tag Referrer desde Javascript

Si no se ha establecido la política a nivel de META Tag, ésta se puede cambiar a nivel de hipervínculo en la etiqueta "A" con el atributo rel="noreferrer", que permitiría evitar en un enlace filtrar la URL de la ubicación del enlace actual.

Figura 12: atributo "noreferrer" en hipervínculos

Éste, como se puede ver en la imagen siguiente suele ir acompañado del modificador noopener que evita ataques de phishing en enlaces con target=_blank, como ya os conté hace tiempo, y que pueden ser muy peligrosos para la seguridad de tu sitio web.

Figura 13: HTTP Header Server-Side "Referrer-Policy"

Por último, y esto es algo que es bastante novedoso, se puede utilizar un HTTP Header llamado Referrer-Policy a nivel de servidor web, para que el propio servidor, sin necesidad de que una aplicación web manualmente lo configure, pueda establecer la política que considere adecuada.

Figura 14: HTTP Header Server-Side "Referrer Policy"

En la Figura 14 se puede ver cómo el servidor envía este Header para establecer cuál es la política que se quiere configurar en el navegador. Y utilizando el servicio de Security Headers puedes comprobar si un determinado sitio la está utilizando o no.

Figura 15: Referrer-Policy en Security Headers

Reflexiones finales

Lo importante de esto es que entiendas que cualquier enlace - ya sea dinámico o estático - que no tenga una política Referrer controlada puede ser un leak de información. Si tienes una aplicación web que permite a usuarios inyectar código HTML y generar hipervínculos, o tu aplicación genera enlaces a partir de información dinámica, y no tienes controlada la política Referrer a nivel de enlaces, documentos o servidor web, puedes estar abriendo la puerta a ataques que no te esperas.

Dentro del proceso de fortificación de una aplicación web debes tener en cuenta estas opciones, y por supuesto, si lo que estás haciendo es una auditoría de seguridad o un pentesting, deberías informar al cliente de cuál es el nivel de la política que tiene establecida. Nosotros en nuestro sistema de pentesting persistente Faast miramos con cariño la políticas políticas de fortificación, que van desde los Referrers, la configuración SRI, los filtros AntiXSS y Anti-ClickJacking, las fugas por Metadatos, etcétera,  para reportar una alerta si no están controladas las opciones de fortificación.

Saludos Malignos!