Blog

¿Qué es el envenenamiento de la caché web?

Envenenamiento de caché web

El envenenamiento de la caché web es un ataque en línea en el que un atacante aprovecha las vulnerabilidades de un servidor web y su servidor de caché asociado para almacenar en caché y ofrecer una respuesta HTTP maliciosa a otros usuarios del servidor web. Ciertamente es un bocado, pero lo analizaremos. En este artículo, explicaremos qué es el envenenamiento de la caché web, cómo funciona y qué puede hacer al respecto.

¿Qué es un caché web?

Para comprender los ataques de envenenamiento web, primero debemos comprender qué es realmente un caché web.

Cada vez que realiza una solicitud a un servidor web, a través de su navegador, el servidor web normalmente responderá con una nueva respuesta para cada solicitud. Y el servidor web buscaría y entregaría el recurso solicitado al usuario. Sin un servidor de almacenamiento en caché intermediario entre el dispositivo del usuario y el servidor, el servidor buscaría el recurso solicitado y se lo entregaría al usuario en una nueva respuesta cada vez que se solicitara ese recurso. En un sitio web muy concurrido, esto rápidamente se volvería inmanejable y sobrecargaría el servidor.

Pero con un servidor de caché ubicado entre el usuario y el servidor, el servidor de caché puede almacenar en caché ciertas respuestas y servirlas al usuario desde allí (el servidor de caché) en lugar de que el servidor web busque ese recurso una y otra vez. Esto reduce en gran medida la carga en el servidor web. De hecho, las respuestas enviadas desde el servidor de caché ni siquiera requieren interacción con el servidor web real.

Claves de caché

El servidor de almacenamiento en caché almacenará en caché las respuestas en función de una serie de factores, como la extensión de archivo del recurso solicitado, el tipo de contenido, la ruta, el código de estado y el encabezado de la respuesta. Esto lo determina el administrador del sitio.

Cuando el servidor de caché recibe una solicitud HTTP, debe determinar si hay una respuesta almacenada en caché disponible o si necesita reenviar la solicitud al servidor backend. El servidor de almacenamiento en caché comparará un subconjunto predefinido de parámetros de los encabezados de la solicitud para identificar solicitudes equivalentes. Este subconjunto de parámetros se denomina clave de caché. Y las partes de la solicitud que no están incluidas en la clave de caché se consideran parámetros 'sin clave'. El servidor de caché ignora por completo estos parámetros sin clave. Este último punto es crucial para montar un ataque de envenenamiento de caché exitoso, como veremos más adelante.

Si la clave de caché de dos solicitudes entrantes coincide, el servidor de almacenamiento en caché considera que estas solicitudes son equivalentes y proporcionará la misma respuesta a ambas solicitudes desde la caché. Y esto seguirá sucediendo para todas las solicitudes coincidentes hasta que expire el caché de esa solicitud.

¿Qué puede pasar si sufre un ataque de envenenamiento de la caché web?

El impacto de un ataque de envenenamiento de caché web es difícil de delimitar. Esto se debe a que el impacto del ataque depende esencialmente de dos factores:

Lo que el atacante pudo almacenar en caché con éxito

Según la configuración del servidor web, un atacante puede almacenar en caché con éxito un archivo infectado, un script malicioso, un enlace malicioso o algún otro exploit. Cualquiera de estos vectores de ataque podría usarse para comprometer su información personal, descargar malware en su máquina o realizar una variedad de otros ataques.

Además, tenga en cuenta que un ataque de envenenamiento web puede usarse junto con otros ataques y causar incluso más daño que si se usara de forma aislada.

El volumen de tráfico en las páginas afectadas.

Si nadie visita las páginas comprometidas, no pasará nada. La respuesta envenenada se entregará a los usuarios que realicen solicitudes a las páginas comprometidas mientras el caché esté envenenado. Según la popularidad de las páginas en cuestión, las consecuencias pueden variar desde ningún impacto hasta desastrosas.

Y aunque los cachés caducan, un atacante experimentado puede programar su ataque para volver a envenenar el caché indefinidamente. Asegurarse de que su caché web caduque después de un período fijo es algo que aún debe hacer, pero no se garantiza que frustre un ataque de envenenamiento de caché web. Más adelante veremos cómo protegerse contra ataques de envenenamiento de caché web.

¿Cómo funcionan los ataques de envenenamiento de caché web?

Un ataque típico de envenenamiento de caché web consta de tres pasos básicos:

  1. Encuentra las entradas sin clave
  2. Generar una respuesta maliciosa desde el servidor web
  3. Obtener la respuesta maliciosa en caché

Encontrar entradas sin clave

Los ataques de envenenamiento de caché web se basan en la manipulación de entradas sin clave, como encabezados. Los cachés web ignorarán las entradas sin clave al evaluar si se entrega o no una respuesta almacenada en caché. Esto significa que puede utilizar entradas sin clave para inyectar su carga útil maliciosa y generar una respuesta 'envenenada'. Esta respuesta envenenada, si se almacena en caché, se entregará a todas las solicitudes que coincidan con la clave de caché. Entonces, el primer paso en cada ataque de envenenamiento de caché web es identificar las entradas sin clave que admite el servidor.

Un atacante puede identificar manualmente entradas sin clave agregando entradas aleatorias a las solicitudes y luego esperando a ver si afectan la respuesta del servidor. Pero esto será tedioso y llevará mucho tiempo. Existen herramientas de software que pueden automatizar este proceso, y estas herramientas son las que hacen que este ataque sea práctico.

Generando una respuesta maliciosa desde el servidor web

A partir de ahí, con algunas entradas conocidas sin clave, el atacante necesita descubrir cómo las procesa el servidor web para lograr que genere una respuesta maliciosa. Por lo tanto, el atacante buscará vulnerabilidades para explotar, como que el servidor web refleje la entrada del usuario en la respuesta del servidor sin estar adecuadamente desinfectado o que genere contenido dinámicamente en función de la entrada del usuario. Estos son los tipos de configuraciones erróneas que permiten ataques de envenenamiento de caché web, junto con muchos otros.

Obtener la respuesta maliciosa almacenada en caché

A partir de aquí, el atacante necesita almacenar en caché su carga útil maliciosa. En esta etapa, saben cómo generar una respuesta maliciosa del servidor, pero necesitan engañar al servidor de caché para que acepte su carga útil en el caché.

Por lo tanto, el atacante intentará descubrir la lógica del almacenamiento en caché mediante prueba y error, observando cómo se comporta el caché en cada paso. Con un poco de suerte, podrán almacenar en caché su carga útil en el servidor de caché. Proporcionaremos un ejemplo detallado a continuación. Y a partir de ahí, cualquiera que solicite el mismo recurso recibirá la respuesta de caché envenenada.

Ejemplos detallados de ataques de envenenamiento de caché web

Entrega de una carga útil de secuencias de comandos XSS mediante envenenamiento de caché web

La forma más sencilla de llevar a cabo un ataque de envenenamiento de caché web es explotar la entrada sin clave que se refleja en una respuesta almacenable en caché sin haber sido desinfectada adecuadamente.

Veamos cómo podría ser una solicitud típica y su correspondiente respuesta:

|_+_| |_+_|

En el ejemplo anterior, el valor del encabezado X-Forwarded-Host se utiliza para generar dinámicamente una URL de imagen de Open Graph, que se refleja en la respuesta. En muchos casos, los encabezados X-Fordered-Host se consideran valores sin clave. En nuestro ejemplo, la caché podría envenenarse generando una respuesta que contenga una carga útil XSS simple:

|_+_| |_+_|

Si esta respuesta se almacenara en caché, cualquier usuario que acceda a |_+_| recibiría esta carga útil XSS en lugar del recurso legítimo. Y entonces empiezan a pasarte cosas divertidas...

Explotar el manejo inadecuado de las importaciones de recursos para montar un ataque de envenenamiento de caché web

Algunos sitios web utilizan encabezados sin clave para generar URL dinámicamente para importar recursos, como archivos JavaScript, desde un servidor externo. En este escenario, si el servidor no está configurado correctamente, un atacante puede cambiar el valor del encabezado apropiado a un dominio bajo su control. Y podrían manipular la URL para que apunte a su propio archivo JavaScript malicioso.

Supongamos que el atacante logra almacenar en caché la respuesta que contiene esta URL maliciosa. En ese caso, el JavaScript del atacante se importará y ejecutará en el navegador de cualquier usuario que realice una solicitud con una clave de caché coincidente.

|_+_| |_+_|

El ejemplo de Paypal

En 2017, un investigador de seguridad israelí llamado Omer Gil descubrió que Paypal era vulnerable a ataques de envenenamiento de caché web . Descubrió que al intentar acceder a recursos inexistentes desde el sitio web de Paypal (un archivo CSS o JavaScript, por ejemplo), el servidor de caché proporcionaría respuestas que incluían información personal de otros usuarios. La información del usuario comprometida iba desde direcciones de correo electrónico, saldos de cuentas, los últimos cuatro dígitos de su tarjeta de crédito y más.

Cómo prevenir ataques de envenenamiento de caché web

Hay una forma segura de prevenir ataques de envenenamiento de caché web: desactivar el almacenamiento en caché por completo. Es probable que esto no sea factible para sitios web más grandes, pero algunos sitios más pequeños podrían implementar esta solución. Por ejemplo, si el almacenamiento en caché sólo está habilitado porque es el valor predeterminado para la CDN que está utilizando, es posible que desee pensar si realmente necesita habilitar el almacenamiento en caché o no. Si no lo hace, desactívelo.

Si su sitio web/aplicación realmente requiere almacenamiento en caché, aquí hay algunas pautas que debe seguir:

Sólo almacenar en caché archivos estáticos

Desea habilitar el almacenamiento en caché solo para archivos puramente estáticos que nunca cambian y que no dependen de ninguna entrada del usuario para generar una respuesta en caché. De esta manera, un atacante no podrá engañar a su servidor de caché para que recupere una versión maliciosa de un archivo en lugar del archivo legítimo previsto.

Tenga cuidado con el software de terceros

Muchos, si no la mayoría, de los sitios web/aplicaciones actuales se crean utilizando algunos software de terceros . Su equipo de desarrollo interno puede exigir un alto estándar en lo que respecta a las prácticas de seguridad al codificar. Pero tan pronto como introduces software de terceros en la mezcla, implícitamente estás confiando en la solidez de las prácticas de seguridad de ese equipo de desarrollo de terceros. Si son más débiles que el suyo, ese código de terceros se convierte en su vínculo más débil y su sitio web/aplicación es tan vulnerable como ese código.

No confíe ni confíe en los datos que se encuentran en los encabezados HTTP

Muchas vulnerabilidades del lado del cliente pueden explotarse a través de encabezados HTTP, lo que puede llevar a ataques de secuencias de comandos entre sitios reflejados , entre otros ataques.

Un ataque XSS reflejado es posible cuando un sitio web/aplicación acepta la entrada del usuario y refleja los resultados al usuario (como un campo de búsqueda), pero sin validar la entrada. Simplemente refleja lo que ingresó el usuario. En nuestro ejemplo anterior, se utilizó la preferencia de idioma del usuario.

Por lo tanto, no confíe en los valores de los encabezados HTTP que no forman parte de su clave de caché. Y nunca devuelva encabezados HTTP desde el caché web.

No confíes en las solicitudes GET

Debe considerar que los cuerpos de solicitud GET no son de confianza y debe asegurarse de que los cuerpos de solicitud GET no puedan modificar el contenido de una respuesta. Si el cuerpo de una solicitud GET puede cambiar el contenido de una respuesta, considere usar una solicitud POST en su lugar o omitir el caché por completo.

Realizar pruebas periódicas de vulnerabilidad

Ejecute análisis de vulnerabilidad en su sitio web/aplicación a intervalos regulares para asegurarse de que no sea vulnerable a ataques de secuencias de comandos entre sitios en particular. El análisis periódico de vulnerabilidades también le protegerá de otras amenazas en línea.

Envolver

Si bien solo deshabilitar el almacenamiento en caché por completo puede garantizar que no sufra un ataque de envenenamiento de caché web, las medidas propuestas anteriormente sesgarán considerablemente las probabilidades de no ser víctima de este ataque a su favor. Cualquier sitio/servicio que viva en línea vive en un entorno hostil. Y sin las defensas adecuadas, no vivirá mucho tiempo. Así que todo ayuda.

Como siempre, mantente a salvo.

Ver también:

^