O cache poisoning ocorre quando dados maliciosos são injetados no cache de um navegador, fazendo com que ele sirva conteúdo comprometido mesmo depois do ataque original. Isso pode afetar tanto o cache do navegador quanto o de DNS, chegando a redirecionar usuários para sites maliciosos ou a servir JavaScript alterado. Da perspectiva da segurança client-side, aplicar controles de cache adequados, usar HTTPS e validar os recursos em cache ajuda a prevenir ataques de poisoning. Cabeçalhos de segurança modernos como o Cache-Control e uma configuração correta de SSL/TLS são defesas essenciais.
Cache poisoning é a inserção de dados maliciosos ou incorretos em um cache, de modo que requisições posteriores recebam a versão adulterada. Várias camadas podem ser afetadas. O web cache poisoning abusa da forma como uma CDN ou proxy reverso constrói sua chave de cache, enganando-o para que armazene uma resposta influenciada pelo atacante que depois é entregue a outros usuários. O DNS cache poisoning corrompe os registros de um resolver, fazendo com que um nome de host aponte para o servidor do atacante. O próprio cache de um navegador também pode reter um recurso manipulado. Em cada caso, a entrada envenenada persiste após a requisição original, permitindo que uma única interação afete muitos visitantes seguintes até que o cache expire ou seja limpo.
Um cache envenenado transforma uma única resposta injetada em um ataque duradouro e de amplo alcance. Se a entrada manipulada for um arquivo JavaScript, cada visitante servido a partir desse cache executa o código do atacante, que pode roubar dados, redirecionar usuários ou desfigurar a página, tudo isso enquanto os próprios logs do servidor de origem parecem normais. O DNS poisoning pode redirecionar o tráfego silenciosamente para um site sósia, para phishing ou roubo de credenciais. Como o conteúdo malicioso é entregue por uma infraestrutura em que usuários e navegadores já confiam, ele contorna muitas defesas e pode ser difícil de detectar. O raio de impacto depende de quão amplamente o cache é compartilhado e de quanto tempo as entradas vivem.
Reduza a superfície de ataque servindo tudo por HTTPS com certificados válidos, o que bloqueia a adulteração no caminho que dá origem a muitos ataques de poisoning, e combine isso com HSTS. Configure os caches para gerar a chave a partir de cada entrada da requisição que afete a resposta, evite decisões de cache baseadas em cabeçalhos não incluídos na chave e defina valores deliberados de Cache-Control e TTL. Use resolvers compatíveis com DNSSEC para resistir ao DNS poisoning e Subresource Integrity para que o navegador rejeite um script cujo hash não corresponda mais. Quando um cache envenenado serve um script de terceiros alterado, a análise de payload da cside em seu método Script consegue detectar que o comportamento do código mudou e bloqueá-lo, independentemente de onde o arquivo foi armazenado em cache.
Não, embora estejam relacionados. O cache poisoning armazena uma resposta prejudicial para que outros a recebam. O web cache deception, por outro lado, engana um cache para que armazene a página privada e personalizada de uma vítima sob uma URL que o atacante pode requisitar depois, expondo os dados desse usuário. Um transforma conteúdo compartilhado em arma; o outro vaza conteúdo confidencial.
O HTTPS criptografa e autentica o tráfego entre o navegador e o servidor, de modo que um atacante no caminho não consiga alterar uma resposta silenciosamente e fazer com que ela seja armazenada em cache como legítima. Ele não corrige falhas na forma como uma CDN constrói chaves de cache nem no DNS, então é necessário, mas não suficiente; a configuração correta do cache e o DNSSEC continuam importando.
We answer client-side security questions every day. Bring yours.