Web Cache Deception
PreviousLaboratorio: carga de shell web mediante condición de carreraNextLaboratorio: Explotación del mapeo de rutas para el engaño de caché web
Last updated
El engaño de caché web es una vulnerabilidad que permite a un atacante engañar a una caché web para que almacene contenido dinámico y confidencial. Se debe a discrepancias entre la forma en que el servidor de caché y el servidor de origen manejan las solicitudes.
En un ataque de engaño de caché web, un atacante convence a una víctima para que visite una URL maliciosa, lo que induce al navegador de la víctima a realizar una solicitud ambigua de contenido confidencial. La caché malinterpreta esto como una solicitud de un recurso estático y almacena la respuesta. El atacante puede luego solicitar la misma URL para acceder a la respuesta almacenada en caché, obteniendo acceso no autorizado a información privada.
Es importante distinguir entre el engaño de la caché web y el envenenamiento de la caché web. Si bien ambos aprovechan los mecanismos de almacenamiento en caché, lo hacen de diferentes maneras:
El envenenamiento de caché web manipula las claves de caché para inyectar contenido malicioso en una respuesta almacenada en caché, que luego se envía a otros usuarios.
El engaño de caché web explota las reglas de caché para engañar al caché y lograr que almacene contenido confidencial o privado, al que luego el atacante puede acceder.
Un CDN (Content Delivery Network) es una red de servidores distribuidos en diferentes lugares del mundo que se utiliza para entregar contenido (como imágenes, videos, páginas web, etc.) a los usuarios de manera rápida y eficiente. La idea es que, en lugar de que todos los usuarios tengan que acceder al servidor principal donde se encuentra la información, puedan acceder a un servidor más cercano geográficamente, lo que reduce el tiempo de carga.
Sí, cuando utilizas un CDN, la información de tu sitio web se almacena temporalmente en los servidores del CDN, lo que se conoce como "cachear". Estos servidores están distribuidos en diferentes ubicaciones geográficas, y su función principal es entregar el contenido de tu sitio de manera más rápida a los usuarios que se encuentran cerca de esos servidores.
Así es cómo funciona:
Primera solicitud: Cuando un usuario visita tu sitio web por primera vez, su solicitud se dirige al CDN. Si el contenido que el usuario solicita no está en la caché del servidor CDN más cercano (porque nadie más lo ha solicitado recientemente), el CDN obtiene el contenido del servidor principal de tu sitio (origen) y lo almacena en su caché. Luego, se lo entrega al usuario.
Solicitudes posteriores: Si otro usuario cercano al mismo servidor CDN solicita el mismo contenido, el CDN le entrega el contenido desde su caché, sin necesidad de volver a solicitarlo al servidor principal. Esto acelera la entrega de la página y reduce la carga en tu servidor principal.
En cuanto al cache local del navegador:
El navegador del usuario también guarda en su propia caché ciertos elementos del sitio web, como imágenes, hojas de estilo (CSS), y scripts (JavaScript). La próxima vez que el usuario visite la misma página, el navegador puede cargar estos elementos desde su caché local en lugar de volver a solicitarlos, lo que también acelera la carga de la página.
Un caché web es un sistema que se encuentra entre el servidor de origen y el usuario. Cuando un cliente solicita un recurso estático, la solicitud se dirige primero al caché. Si el caché no contiene una copia del recurso (lo que se conoce como error de caché), la solicitud se reenvía al servidor de origen, que la procesa y responde. Luego, la respuesta se envía al caché antes de enviarse al usuario. El caché utiliza un conjunto de reglas preconfiguradas para determinar si se debe almacenar la respuesta.
Cuando en el futuro se realiza una solicitud del mismo recurso estático, la memoria caché envía la copia almacenada de la respuesta directamente al usuario (lo que se conoce como un acceso de memoria caché).
El almacenamiento en caché se ha convertido en un aspecto común y crucial de la distribución de contenido web, en particular con el uso generalizado de las redes de distribución de contenido (CDN), que utilizan el almacenamiento en caché para almacenar copias de contenido en servidores distribuidos por todo el mundo. Las CDN aceleran la distribución al ofrecer el contenido desde el servidor más cercano al usuario, lo que reduce los tiempos de carga al minimizar la distancia que recorren los datos.
Cuando la caché recibe una solicitud HTTP, debe decidir si hay una respuesta almacenada en caché que puede atender directamente o si tiene que reenviar la solicitud al servidor de origen. La caché toma esta decisión generando una "clave de caché" a partir de elementos de la solicitud HTTP. Normalmente, esto incluye la ruta URL y los parámetros de consulta, pero también puede incluir una variedad de otros elementos como encabezados y tipo de contenido.
Si la clave de caché de la solicitud entrante coincide con la de una solicitud anterior, la caché las considera equivalentes y sirve una copia de la respuesta almacenada en caché.
Las reglas de caché determinan qué se puede almacenar en caché y durante cuánto tiempo. Las reglas de caché suelen configurarse para almacenar recursos estáticos, que generalmente no cambian con frecuencia y se reutilizan en varias páginas. El contenido dinámico no se almacena en caché, ya que es más probable que contenga información confidencial, lo que garantiza que los usuarios obtengan los datos más recientes directamente del servidor.
Los ataques de engaño de caché web aprovechan la forma en que se aplican las reglas de caché, por lo que es importante conocer algunos tipos diferentes de reglas, en particular las basadas en cadenas definidas en la ruta URL de la solicitud. Por ejemplo:
Reglas de extensión de archivo estáticas: estas reglas coinciden con la extensión de archivo del recurso solicitado, por ejemplo, .csspara hojas de estilo o .js para archivos JavaScript.
Reglas de directorio estático: estas reglas coinciden con todas las rutas URL que comienzan con un prefijo específico. Suelen utilizarse para directorios específicos que contienen solo recursos estáticos, por ejemplo, /statico /assets.
Reglas de nombre de archivo: estas reglas hacen coincidir nombres de archivos específicos con archivos de destino que son universalmente necesarios para operaciones web y cambian con poca frecuencia, como robots.txty favicon.ico
Los cachés también pueden implementar reglas personalizadas basadas en otros criterios, como parámetros de URL o análisis dinámico.
En términos generales, construir un ataque básico de engaño de caché web implica los siguientes pasos:
Identifique un punto final de destino que devuelva una respuesta dinámica que contenga información confidencial. Revise las respuestas en Burp, ya que es posible que parte de la información confidencial no esté visible en la página representada. Concéntrese en los puntos finales que admitan los métodos GET, HEADo , OPTIONSya que las solicitudes que alteran el estado del servidor de origen generalmente no se almacenan en caché.
Identifique una discrepancia en la forma en que el servidor de origen y el caché analizan la ruta URL. Esto podría deberse a una discrepancia en la forma en que:
Asignar URL a recursos.
Procesar caracteres delimitadores.
Normalizar rutas.
Cree una URL maliciosa que utilice la discrepancia para engañar a la caché y que almacene una respuesta dinámica. Cuando la víctima accede a la URL, su respuesta se almacena en la caché. Con Burp, puede enviar una solicitud a la misma URL para obtener la respuesta almacenada en caché que contiene los datos de la víctima. Evite hacer esto directamente en el navegador, ya que algunas aplicaciones redirigen a los usuarios sin una sesión o invalidan los datos locales, lo que podría ocultar una vulnerabilidad.
Al probar si existen discrepancias y crear un exploit para engañar a los usuarios con caché web, asegúrese de que cada solicitud que envíe tenga una clave de caché diferente. De lo contrario, es posible que reciba respuestas almacenadas en caché, lo que afectará los resultados de la prueba.
Como tanto la ruta URL como los parámetros de consulta suelen estar incluidos en la clave de caché, puedes cambiar la clave agregando una cadena de consulta a la ruta y cambiándola cada vez que envíes una solicitud. Automatice este proceso utilizando la extensión Param Miner. Para ello, una vez que haya instalado la extensión, haga clic en el menú de nivel superior Param miner > Configuración y, a continuación, seleccione Agregar caché dinámico . Burp ahora agrega una cadena de consulta única a cada solicitud que realice. Puede ver las cadenas de consulta agregadas en la pestaña Registrador .
Durante las pruebas, es fundamental que puedas identificar las respuestas almacenadas en caché. Para ello, observa los encabezados de respuesta y los tiempos de respuesta.
Varios encabezados de respuesta pueden indicar que se almacena en caché. Por ejemplo:
El X-Cache
encabezado proporciona información sobre si se entregó una respuesta desde la memoria caché. Los valores típicos incluyen:
X-Cache: hit
La respuesta se sirvió desde la caché.
X-Cache: miss
La memoria caché no contenía una respuesta para la clave de la solicitud, por lo que se obtuvo del servidor de origen. En la mayoría de los casos, la respuesta se almacena en caché. Para confirmarlo, vuelva a enviar la solicitud para ver si el valor se actualiza para confirmar.
X-Cache: dynamic
El servidor de origen generó el contenido de forma dinámica. Por lo general, esto significa que la respuesta no es adecuada para el almacenamiento en caché.
X-Cache: refresh
El contenido almacenado en caché estaba desactualizado y era necesario actualizarlo o revalidarlo.
El Cache-Controlencabezado puede incluir una directiva que indique el almacenamiento en caché, como public con un max-agevalor mayor que 0.Tenga en cuenta que esto solo sugiere que el recurso se puede almacenar en caché. No siempre es indicativo de almacenamiento en caché, ya que la caché a veces puede anular este encabezado.
Si noto una gran diferencia en el tiempo de respuesta para la misma solicitud, esto también puede indicar que la respuesta más rápida se sirve desde el caché.
Las reglas de caché suelen apuntar a recursos estáticos mediante la coincidencia de extensiones de archivos comunes como .csso .js. Este es el comportamiento predeterminado en la mayoría de las CDN.
Si hay discrepancias en cómo el caché y el servidor de origen asignan la ruta URL a los recursos o usan delimitadores, un atacante puede crear una solicitud para un recurso dinámico con una extensión estática que es ignorada por el servidor de origen pero vista por el caché.
El mapeo de rutas URL es el proceso de asociar rutas URL con recursos en un servidor, como archivos, scripts o ejecuciones de comandos. Existen distintos estilos de mapeo utilizados por diferentes marcos y tecnologías. Dos estilos comunes son el mapeo de URL tradicional y el mapeo de URL RESTful.
La asignación de URL tradicional representa una ruta directa a un recurso ubicado en el sistema de archivos. A continuación, se muestra un ejemplo típico:
http://example.com/path/in/filesystem/resource.html
http://example.comapunta al servidor.
/path/in/filesystem/representa la ruta del directorio en el sistema de archivos del servidor.
resource.htmles el archivo específico al que se está accediendo.
Por el contrario, las URL de estilo REST no coinciden directamente con la estructura física del archivo, sino que abstraen las rutas de archivo en partes lógicas de la API:
http://example.com/path/resource/param1/param2
http://example.comapunta al servidor.
/path/resource/es un punto final que representa un recurso.
param1param2son parámetros de ruta utilizados por el servidor para procesar la solicitud.
Las discrepancias en la forma en que el servidor de origen y el caché asignan la ruta URL a los recursos pueden generar vulnerabilidades de engaño de caché web. Considere el siguiente ejemplo:
http://example.com/user/123/profile/wcd.css
Un servidor de origen que utiliza mapeo de URL de estilo REST puede interpretar esto como una solicitud para el /user/123/profilepunto final y devolver la información del perfil del usuario 123, ignorándolo wcd.css como un parámetro no significativo.
Una caché que utiliza la asignación de URL tradicional puede ver esto como una solicitud de un archivo llamado wcd.cssubicado en el /profiledirectorio bajo /user/123. Interpreta la ruta URL como /user/123/profile/wcd.css. Si la caché está configurada para almacenar respuestas a solicitudes donde la ruta termina en .css, almacenará en caché y entregará la información del perfil como si fuera un archivo CSS.
Para probar cómo el servidor de origen asigna la ruta URL a los recursos, agregue un segmento de ruta arbitrario a la URL de su punto final de destino. Si la respuesta aún contiene los mismos datos confidenciales que la respuesta base, indica que el servidor de origen abstrae la ruta URL e ignora el segmento agregado. Por ejemplo, este es el caso si la modificación /api/orders/123aún /api/orders/123/foodevuelve información de pedidos.
Para probar cómo la caché asigna la ruta URL a los recursos, deberá modificar la ruta para intentar que coincida con una regla de caché agregando una extensión estática. Por ejemplo, actualizar /api/orders/123/fooa /api/orders/123/foo.js. Si la respuesta está almacenada en caché, esto indica:
Que el caché interprete la ruta URL completa con la extensión estática.
Que existe una regla de caché para almacenar las respuestas de las solicitudes que terminan en .js.
Los cachés pueden tener reglas basadas en extensiones estáticas específicas. Pruebe una variedad de extensiones, incluidas .css, .ico, y .exe.
Luego, puede crear una URL que devuelva una respuesta dinámica que se almacena en la memoria caché. Tenga en cuenta que este ataque está limitado al punto final específico que probó, ya que el servidor de origen suele tener diferentes reglas de abstracción para diferentes puntos finales.
Los delimitadores especifican límites entre los distintos elementos de las URL. El uso de caracteres y cadenas como delimitadores suele estar estandarizado. Por ejemplo, ?se utiliza generalmente para separar la ruta de la URL de la cadena de consulta. Sin embargo, como la RFC de URI es bastante permisiva, aún se producen variaciones entre los distintos marcos o tecnologías.
Las discrepancias en la forma en que el servidor de origen y el de caché utilizan caracteres y cadenas como delimitadores pueden generar vulnerabilidades de engaño de caché web. Considere el siguiente ejemplo /profile;foo.css:
El marco de Java Spring utiliza el ;carácter para agregar parámetros conocidos como variables de matriz. Por lo tanto, un servidor de origen que utiliza Java Spring lo interpretaría como un delimitador. Trunca la ruta después y devuelve información del perfil.
La mayoría de los demás marcos no utilizan ;como delimitador. Por lo tanto, es probable que una caché que no utilice Java Spring interprete ; y todo lo que esté después como parte de la ruta. Si la caché tiene una regla para almacenar respuestas a solicitudes que terminan en .css, podría almacenar en caché y servir la información del perfil como si fuera un archivo CSS.
Lo mismo sucede con otros caracteres que se utilizan de forma inconsistente entre marcos o tecnologías. Considere estas solicitudes a un servidor de origen que ejecuta el marco Ruby on Rails, que utiliza .como delimitador para especificar el formato de respuesta:
/profileEsta solicitud es procesada por el formateador HTML predeterminado, que devuelve la información del perfil del usuario.
/profile.cssEsta solicitud se reconoce como una extensión CSS. No hay un formateador CSS, por lo que no se acepta la solicitud y se devuelve un error.
/profile.icoEsta solicitud utiliza la .ico extensión , que Ruby on Rails no reconoce. El formateador HTML predeterminado maneja la solicitud y devuelve la información del perfil del usuario. En esta situación, si la memoria caché está configurada para almacenar respuestas a solicitudes que terminan en .ico, almacenaría en caché y mostraría la información del perfil como si fuera un archivo estático.
A veces también se pueden utilizar caracteres codificados como delimitadores. Por ejemplo, considere la solicitud /profile%00foo.js:
El servidor OpenLiteSpeed utiliza el %00carácter nulo codificado como delimitador. Por lo tanto, un servidor de origen que utilice OpenLiteSpeed interpretaría la ruta como /profile.
La mayoría de los demás marcos responden con un error si %00está en la URL. Sin embargo, si la caché utiliza Akamai o Fastly, interpretará %00todo lo que esté después como la ruta.
A veces, los sitios web necesitan enviar datos en la URL que contienen caracteres que tienen un significado especial dentro de las URL, como los delimitadores. Para garantizar que estos caracteres se interpreten como datos, normalmente se codifican. Sin embargo, algunos analizadores decodifican ciertos caracteres antes de procesar la URL. Si se decodifica un carácter delimitador, puede tratarse como tal y trunca la ruta de la URL.
Las diferencias en la forma en que el servidor de origen y el de caché decodifican los caracteres delimitadores pueden generar discrepancias en la forma en que interpretan la ruta URL, incluso si ambos utilizan los mismos caracteres como delimitadores. Considere el ejemplo /profile%23wcd.css, que utiliza el carácter codificado en URL #:
El servidor de origen decodifica %23como #. Lo utiliza # como delimitador, por lo que interpreta la ruta como /profile y devuelve información del perfil.
La caché también utiliza el #carácter como delimitador, pero no decodifica %23. Interpreta la ruta como /profile%23wcd.css. Si existe una regla de caché para la extensión .css, almacenará la respuesta.
Es posible aprovechar una discrepancia de decodificación utilizando un delimitador codificado para agregar una extensión estática a la ruta que ve la memoria caché, pero no el servidor de origen.
Utilice la misma metodología de prueba que utilizó para identificar y explotar las discrepancias entre delimitadores, pero utilice un rango de caracteres codificados. Asegúrese de probar también los caracteres no imprimibles codificados, en particular %00, %0Ay %09. Si estos caracteres se decodifican, también pueden truncar la ruta URL.
Los delimitadores codeados a URL →
Es una práctica común que los servidores web almacenen recursos estáticos en directorios específicos. Las reglas de caché suelen apuntar a estos directorios al hacer coincidir prefijos de rutas URL específicos, como /static, /assets, /scriptso /images. Estas reglas también pueden ser vulnerables al engaño de caché web.
La normalización implica convertir varias representaciones de rutas URL a un formato estandarizado. Esto a veces incluye la decodificación de caracteres codificados y la resolución de segmentos de puntos, pero esto varía significativamente de un analizador a otro.
Las discrepancias en la forma en que el servidor de origen y el caché normalizan la URL pueden permitir que un atacante construya una carga útil de recorrido de ruta que cada analizador interprete de manera diferente. Considere el ejemplo /static/..%2fprofile:
Un servidor de origen que decodifica caracteres de barra y resuelve segmentos de puntos normalizaría la ruta /profiley devolvería información del perfil.
Una caché que no resuelva segmentos de puntos ni decodifique barras interpretaría la ruta como /static/..%2fprofile. Si la caché almacena respuestas a solicitudes con el /staticprefijo, almacenaría en caché y proporcionaría la información del perfil.
Como se muestra en el ejemplo anterior, cada segmento de punto en la secuencia de recorrido de ruta debe estar codificado. De lo contrario, el navegador de la víctima lo resolverá antes de reenviar la solicitud a la memoria caché. Por lo tanto, una discrepancia de normalización explotable requiere que la memoria caché o el servidor de origen decodifiquen los caracteres en la secuencia de recorrido de ruta y resuelvan los segmentos de punto.
Para probar cómo el servidor de origen normaliza la ruta URL, envíe una solicitud a un recurso no almacenable en caché con una secuencia de recorrido de ruta y un directorio arbitrario al comienzo de la ruta. Para elegir un recurso no almacenable en caché, busque un método no idempotente como POST. Por ejemplo, modifique /profilea /aaa/..%2fprofile:
%2f == /
Si la respuesta coincide con la respuesta base y devuelve la información del perfil, esto indica que la ruta se interpretó como /profile. El servidor de origen decodifica la barra y resuelve el segmento de punto.
Si la respuesta no coincide con la respuesta base (por ejemplo, si se devuelve un 404mensaje de error), esto indica que la ruta se interpretó como /aaa/..%2fprofile. El servidor de origen no decodifica la barra o no resuelve el segmento de punto.
Al realizar pruebas de normalización, comience codificando solo la segunda barra en el segmento de punto. Esto es importante porque algunas CDN coinciden con la barra que sigue al prefijo del directorio estático.
También puedes intentar codificar la secuencia de recorrido de ruta completa o codificar un punto en lugar de una barra. Esto a veces puede afectar la decodificación de la secuencia por parte del analizador.
Puede utilizar algunos métodos diferentes para probar cómo la caché normaliza la ruta. Comience por identificar los posibles directorios estáticos. En Proxy > Historial HTTP , busque solicitudes con prefijos de directorio estático comunes y respuestas almacenadas en caché. Concéntrese en los recursos estáticos configurando el filtro de historial HTTP para que muestre solo los mensajes con respuestas 2xx y tipos MIME de scripts, imágenes y CSS.
Luego, puede elegir una solicitud con una respuesta almacenada en caché y reenviarla con una secuencia de recorrido de ruta y un directorio arbitrario al comienzo de la ruta estática. Elija una solicitud con una respuesta que contenga evidencia de estar almacenada en caché. Por ejemplo /aaa/..%2fassets/js/stockCheck.js:
Si la respuesta ya no se almacena en caché, esto indica que la caché no está normalizando la ruta antes de asignarla al punto final. Esto demuestra que hay una regla de caché basada en el /assetsprefijo.
Si la respuesta aún está almacenada en caché, esto puede indicar que el caché ha normalizado la ruta a /assets/js/stockCheck.js.
También puede agregar una secuencia de recorrido de ruta después del prefijo del directorio. Por ejemplo, modifíquelo /assets/js/stockCheck.jsde la siguiente manera /assets/..%2fjs/stockCheck.js:
Si la respuesta ya no se almacena en caché, esto indica que la caché decodifica la barra y resuelve el segmento de punto durante la normalización, interpretando la ruta como /js/stockCheck.js/assets. Esto demuestra que existe una regla de caché basada en el prefijo.
Si la respuesta aún está almacenada en caché, esto puede indicar que el caché no ha decodificado la barra o resuelto el segmento de punto, interpretando la ruta como /assets/..%2fjs/stockCheck.js.
Tenga en cuenta que, en ambos casos, la respuesta puede almacenarse en caché debido a otra regla de caché, como una basada en la extensión del archivo. Para confirmar que la regla de caché se basa en el directorio estático, reemplace la ruta después del prefijo del directorio con una cadena arbitraria. Por ejemplo, /assets/aaa. Si la respuesta aún está almacenada en caché, esto confirma que la regla de caché se basa en el /assetsprefijo. Tenga en cuenta que si la respuesta no parece estar almacenada en caché, esto no descarta necesariamente una regla de caché de directorio estático, ya que a veces 404las respuestas no se almacenan en caché.
Es posible que no puedas determinar definitivamente si la caché decodifica segmentos de puntos y decodifica la ruta URL sin intentar una explotación.
Si el servidor de origen resuelve segmentos de puntos codificados, pero el caché no, puede intentar explotar la discrepancia construyendo una carga útil de acuerdo con la siguiente estructura:
Por ejemplo, considere la carga útil /assets/..%2fprofile
La caché interpreta la ruta como:/assets/..%2fprofile
El servidor de origen interpreta la ruta como:/profile
El servidor de origen devuelve la información del perfil dinámico, que se almacena en la memoria caché.
Si el servidor de caché resuelve segmentos de puntos codificados pero el servidor de origen no lo hace, puede intentar explotar la discrepancia construyendo una carga útil de acuerdo con la siguiente estructura:
Al aprovechar la normalización del servidor de caché, codifique todos los caracteres en la secuencia de recorrido de ruta. El uso de caracteres codificados ayuda a evitar un comportamiento inesperado al usar delimitadores y no es necesario tener una barra sin codificar después del prefijo del directorio estático, ya que la caché se encargará de la decodificación.
En esta situación, el solo hecho de atravesar la ruta no es suficiente para explotar el exploit. Por ejemplo, considere cómo el servidor de origen y el caché interpretan la carga útil /profile%2f%2e%2e%2fstatic:
La caché interpreta la ruta como:/static
El servidor de origen interpreta la ruta como:/profile%2f%2e%2e%2fstatic
Es probable que el servidor de origen devuelva un mensaje de error en lugar de información de perfil.
Para aprovechar esta discrepancia, también deberá identificar un delimitador que utilice el servidor de origen, pero no la memoria caché. Pruebe los posibles delimitadores agregándolos a la carga útil después de la ruta dinámica:
Si el servidor de origen utiliza un delimitador, truncará la ruta URL y devolverá la información dinámica.
Si la caché no utiliza el delimitador, resolverá la ruta y almacenará en caché la respuesta.
Por ejemplo, considere la carga útil /profile;%2f%2e%2e%2fstatic. El servidor de origen utiliza ;como delimitador:
La caché interpreta la ruta como:/static
El servidor de origen interpreta la ruta como:/profile
El servidor de origen devuelve la información del perfil dinámico, que se almacena en la memoria caché. Por lo tanto, puede utilizar esta carga útil para un exploit.
Ciertos archivos, como robots.txt, index.htmly favicon.icoson archivos comunes que se encuentran en los servidores web. A menudo se almacenan en caché debido a que no se modifican con frecuencia. Las reglas de caché se enfocan en estos archivos al hacer coincidir la cadena de nombre de archivo exacta.
Para identificar si existe una regla de caché de nombre de archivo, envíe una GETsolicitud de un posible archivo y vea si la respuesta está almacenada en caché.
Para probar cómo la caché normaliza la ruta de la URL, envíe una solicitud con una secuencia de recorrido de ruta y un directorio arbitrario antes del nombre del archivo. Por ejemplo /aaa%2f%2e%2e%2findex.html:
Si la respuesta se almacena en caché, esto indica que el caché normaliza la ruta a /index.html
Si la respuesta no se almacena en caché, esto indica que el caché no decodifica la barra ni resuelve el segmento de punto, interpretando la ruta como /profile%2f%2e%2e%2findex.html
Puede tomar una serie de medidas para evitar vulnerabilidades de engaño de caché web:
Utilice siempre Cache-Controlencabezados para marcar recursos dinámicos, configúrelos con las directivas no-storey private
Configure los ajustes de su CDN para que sus reglas de almacenamiento en caché no anulen el Cache-Controlencabezado.
Activa cualquier protección que tenga tu CDN contra ataques de engaño de caché web. Muchas CDN te permiten configurar una regla de caché que verifica que la respuesta Content-Typecoincida con la extensión del archivo URL de la solicitud. Por ejemplo, Cache Deception Armor de Cloudflare.
Verifique que no haya discrepancias entre cómo el servidor de origen y la caché interpretan las rutas URL.
Url Web Cache Scanner BURP:
Para probar cómo el servidor de origen normaliza la ruta URL, utilice el mismo método que utilizó para las reglas de caché de directorio estático. Para obtener más información, consulte .
Dado que la respuesta solo se almacena en caché si la solicitud coincide con el nombre de archivo exacto, solo se puede aprovechar una discrepancia en la que el servidor de caché resuelve los segmentos de puntos codificados, pero el servidor de origen no. Utilice el mismo método que para las reglas de caché de directorio estático: simplemente reemplace el prefijo de directorio estático con el nombre de archivo. Para obtener más información, consulte .
