Skip to main content
Todos los Términos Glossary

Envenenamiento de caché

Definition

El envenenamiento de la caché se produce cuando se inyectan datos maliciosos en la caché de un navegador, lo que hace que sirva contenido comprometido incluso después del ataque original. Esto puede afectar tanto a las cachés del navegador como a las de DNS, redirigiendo potencialmente a los usuarios a sitios maliciosos o sirviendo JavaScript alterado. Desde la perspectiva de la seguridad del lado del cliente, la implementación de controles de caché adecuados, el uso de HTTPS y la validación de los recursos en caché ayudan a prevenir los ataques de envenenamiento. Los encabezados de seguridad modernos como Cache-Control y la configuración adecuada de SSL/TLS son defensas cruciales.

Qué es el envenenamiento de caché

El envenenamiento de caché (cache poisoning) es la inserción de datos maliciosos o incorrectos en una caché para que las solicitudes posteriores reciban la versión manipulada. Pueden verse afectadas varias capas. El envenenamiento de caché web abusa de cómo una CDN o un proxy inverso construye su clave de caché, engañándolo para que almacene una respuesta influida por el atacante que luego se entrega a otros usuarios. El envenenamiento de caché DNS corrompe los registros de un resolutor para que un nombre de host apunte al servidor del atacante. La propia caché del navegador también puede conservar un recurso manipulado. En todos los casos, la entrada envenenada persiste después de la solicitud original, dejando que una sola interacción afecte a muchos visitantes posteriores hasta que la caché caduque o se purgue.

Por qué importa el envenenamiento de caché

Una caché envenenada convierte una única respuesta inyectada en un ataque duradero y de gran alcance. Si la entrada manipulada es un archivo JavaScript, todos los visitantes servidos desde esa caché ejecutan el código del atacante, que puede robar datos, redirigir a los usuarios o desfigurar la página, todo ello mientras los propios registros del servidor de origen parecen normales. El envenenamiento de DNS puede reencaminar el tráfico de forma silenciosa hacia un sitio clonado para hacer phishing o robar credenciales. Como el contenido malicioso se entrega desde una infraestructura en la que los usuarios y navegadores ya confían, esquiva muchas defensas y puede ser difícil de detectar. El radio de impacto depende de cuán ampliamente se comparta la caché y de cuánto vivan las entradas.

Cómo defenderse del envenenamiento de caché

Reduce la superficie de ataque sirviendo todo por HTTPS con certificados válidos, lo que bloquea la manipulación en ruta que siembra muchos ataques de envenenamiento, y combínalo con HSTS. Configura las cachés para que incluyan en la clave cada entrada de la solicitud que afecte a la respuesta, evita las decisiones de caché basadas en cabeceras no incluidas en la clave y define valores deliberados de Cache-Control y TTL. Usa resolutores compatibles con DNSSEC para resistir el envenenamiento de DNS, y Subresource Integrity para que el navegador rechace un script cuyo hash ya no coincide. Cuando una caché envenenada sirve un script de terceros alterado, el análisis de carga útil que hace cside en su método Script puede detectar que el comportamiento del código ha cambiado y bloquearlo, sin importar dónde se haya almacenado en caché el archivo.

Definition

¿El envenenamiento de caché es lo mismo que el engaño de caché web (web cache deception)?

No, aunque están relacionados. El envenenamiento de caché almacena una respuesta dañina para que otros la reciban. El engaño de caché web, en cambio, engaña a una caché para que almacene la página privada y personalizada de una víctima bajo una URL que el atacante puede solicitar después, exponiendo los datos de ese usuario. Uno convierte en arma el contenido compartido; el otro filtra contenido confidencial.

Definition

¿Cómo ayuda HTTPS contra el envenenamiento de caché?

HTTPS cifra y autentica el tráfico entre el navegador y el servidor, de modo que un atacante en ruta no puede alterar en silencio una respuesta y hacer que se almacene en caché como legítima. No corrige los fallos en cómo una CDN construye las claves de caché ni en el DNS, así que es necesario pero no suficiente; una configuración de caché correcta y DNSSEC siguen importando.

Got more questions

Talk to a security expert

We answer client-side security questions every day. Bring yours.

Reservar una demo

¿Quieres verlo en detalle con un ingeniero?

Treinta minutos, sobre tu propio sitio. Nada de diapositivas.

Te enseñaremos:

Qué scripts de terceros se están ejecutando ahora mismo en tu sitio
En qué punto estás con los requisitos 6.4.3 y 11.6.1 de PCI DSS
Qué parte de tu tráfico son bots y agentes de IA

¿Prefieres mandarnos una pregunta?

Buscando huecos libres…

Solo humanos de verdad. Nos daríamos cuenta.

¿Problemas para reservar? Abrir el calendario en una pestaña nueva

¿Qué quieres resolver?

Cuéntanoslo en una línea y te responderemos con algo útil, no con un discurso genérico.

Solemos ayudar con:

Ver qué scripts de terceros se ejecutan en tu sitio
Evidencias para PCI DSS 6.4.3 y 11.6.1
Bots, agentes de IA y robo de cuentas

¿Prefieres reservar una hora? Elegir un hueco