Melhore a segurança e a privacidade atualizando o cache HTTP

Esquecer ou usar indevidamente o cabeçalho Cache-Control pode afetar negativamente a segurança do seu site e a privacidade dos usuários.

Arthur Sonzogni
Arthur Sonzogni

Por padrão, os recursos sempre podem ser armazenados em cache por qualquer tipo de cache. Não usar ou usar indevidamente o cabeçalho Cache-Control pode afetar negativamente a segurança do seu site e a privacidade dos usuários.

Para respostas personalizadas que você quer manter em sigilo, recomendamos:

  • Impeça que os intermediários armazenem o recurso em cache. Defina Cache-Control: private.
  • Defina uma chave de cache secundária adequada. Se a resposta variar devido a cookies, o que pode acontecer quando o cookie armazena credenciais, defina Vary: Cookie.

Continue lendo para saber por que isso é importante e descobrir:

  1. Problemas de segurança e privacidade que você talvez não conheça
  2. Diferentes tipos de caches HTTP e equívocos comuns
  3. Ações recomendadas para sites de alto valor

Recursos com vazamento de vulnerabilidades Spectre

A vulnerabilidade Spectre permite que uma página leia a memória de um processo do SO. Isso significa que um invasor pode ter acesso não autorizado a dados de várias origens. Como consequência, os navegadores da Web modernos restringiram o uso de alguns recursos, como SharedArrayBuffer ou timer de alta resolução, para páginas com isolamento de origem cruzada.

Os navegadores da Web modernos aplicam a política de incorporador entre origens (COEP, na sigla em inglês). Isso garante que os recursos de origem cruzada sejam:

  • Recursos públicos solicitados sem cookies
  • Recursos explicitamente permitidos para compartilhamento entre origens, via CORS ou o cabeçalho CORP.

A configuração de COEP não impede que um invasor explore o Spectre. No entanto, ele garante que os recursos de origem cruzada não sejam valiosos para o invasor (quando carregados pelo navegador como recurso público) ou que não possam ser compartilhados com o invasor (quando compartilhados com CORP: cross-origin).

Como o armazenamento em cache HTTP afeta o Spectre?

Se o cabeçalho Cache-Control não estiver definido corretamente, um invasor poderá executar um ataque. Exemplo:

  1. O recurso com credenciais é armazenado em cache.
  2. O invasor carrega uma página isolada entre origens.
  3. O invasor solicita o recurso novamente.
  4. COEP:credentialless é definido pelo navegador, para que o recurso seja buscado sem cookies. No entanto, um cache pode retornar a resposta de credencial.
  5. O invasor pode ler o recurso personalizado usando um ataque Spectre.

Embora o cache HTTP de um navegador da Web não permita que esse tipo de ataque aconteça na prática, outros caches existem fora do controle imediato do navegador. Isso pode levar ao sucesso do ataque.

Equívocos comuns sobre caches HTTP

1. Os recursos são armazenados em cache apenas pelo navegador

Geralmente, há várias camadas de cache. Alguns caches são dedicados a um usuário, outros a vários usuários. Algumas são controladas pelo servidor, outras pelo usuário e outras por intermediários.

  • Caches do navegador. Esses caches são de propriedade e dedicados a um único usuário, implementado no navegador da Web. Eles melhoram o desempenho evitando buscar a mesma resposta várias vezes.
  • Proxy local. Ele pode ter sido instalado pelo usuário, mas também pode ser gerenciado por intermediários: a empresa, a organização ou o provedor de Internet. Os proxies locais geralmente armazenam em cache uma única resposta para vários usuários, o que constitui um cache "público". Os proxies locais têm várias funções.
  • Cache do servidor de origem / CDN. Isso é controlado pelo servidor. O objetivo do cache do servidor de origem é reduzir a carga no servidor de origem armazenando em cache a mesma resposta para vários usuários. As metas de um CDN são semelhantes, mas estão espalhadas pelo mundo e atribuídas ao conjunto de usuários mais próximo para reduzir a latência.
Muitas vezes, há várias camadas de cache entre o navegador e o servidor.
Pode haver várias camadas de cache entre o navegador e o servidor. Por exemplo, você pode encontrar um cache do servidor, seguido por um CDN e o cache do navegador. Também pode haver uma configuração de proxy local entre a CDN e o cache do navegador.

2. O SSL impede que os intermediários armazenem em cache os recursos HTTPS

Muitos usuários usam regularmente proxies configurados localmente, seja para fins de acesso, como compartilhar uma conexão limitada, inspeção de vírus ou prevenção contra perda de dados (DLP, na sigla em inglês). O cache intermediário está realizando a interceptação de TLS.

Um cache intermediário geralmente é instalado nas estações de trabalho de um funcionário da empresa. Os navegadores da Web são configurados para confiar nos certificados do proxy local.

Alguns recursos HTTPS podem ser armazenados em cache por esses proxies locais.

Como o cache HTTP funciona

  • Por padrão, os recursos são implicitamente permitidos de serem armazenados em cache.
  • A chave de cache principal consiste no URL e no método. (URL, método)
  • A chave de cache secundária são os cabeçalhos incluídos no cabeçalho Vary. Vary: Cookie indica que a resposta depende do Cookie.
  • O cabeçalho Cache-Control oferece um controle mais granular.

Os desenvolvedores de sites de alto valor, que incluem sites com tráfego alto e que interagem com informações de identificação pessoal, precisam agir agora para melhorar a segurança.

O maior risco ocorre quando o acesso a um recurso varia de acordo com os cookies. Um cache intermediário pode retornar uma resposta solicitada com cookies para uma solicitação que não foi feita se nenhuma ação preventiva tiver sido realizada.

Recomendamos que você siga uma destas etapas:

  • Impeça que os intermediários armazenem o recurso em cache. Defina Cache-Control: private.
  • Defina uma chave de cache secundária adequada. Se a resposta variar devido a cookies, o que pode acontecer quando o cookie armazena credenciais, defina Vary: Cookie.

Especifique sempre Cache-Control ou Vary.

Outras considerações

Há outros tipos de ataques semelhantes que usam o cache HTTP, mas eles dependem de um mecanismo diferente do isolamento entre origens. Por exemplo, Jake Archibald descreve alguns ataques em Como vencer o CORS.

Esses ataques são mitigados por alguns navegadores da Web que dividem o cache HTTP dependendo se a resposta do recurso foi solicitada com credenciais ou não. Em 2022, o Firefox divide o cache, mas o Chrome e o Safari não. O Chrome pode dividir o cache no futuro. Observe que esses ataques são diferentes e complementares para dividir por origem de nível superior.

Mesmo que esse problema possa ser mitigado para navegadores da Web, ele permanecerá nos caches de proxy locais. Portanto, ainda sugerimos que você siga as recomendações acima.

Foto do cabeçalho de Ben Pattinson no Unsplash.