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

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

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

Para manter a privacidade das respostas personalizadas, recomendamos que você faça o seguinte:

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

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

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

Riscos de segurança e privacidade relacionados ao cache

Recursos vazados 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 origem cruzada. Como consequência, os navegadores da Web modernos restringiram o uso de alguns recursos, como SharedArrayBuffer ou timer de alta resolução, a páginas com isolamento de origem cruzada.

Os navegadores da Web modernos aplicam a Política de incorporação de origem cruzada (COEP, na sigla em inglês). Isso garante que os recursos de origem cruzada:

• Recursos públicos, solicitados sem cookies
• Recursos com permissão explícita para serem compartilhados de origem cruzada, via CORS ou o cabeçalho CORP.

A configuração do COEP não impede que um invasor explore o Spectre. No entanto, garante que os recursos de origem cruzada não tenham valor para o invasor (quando carregados pelo navegador como recurso público) ou 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 for definido corretamente, um invasor poderá executar um ataque. Exemplo:

1. O recurso credenciado é armazenado em cache.
2. O invasor carrega uma página isolada de origem cruzada.
3. O invasor solicita o recurso novamente.
4. O COEP:credentialless é definido pelo navegador, de modo que o recurso é buscado sem cookies. No entanto, um cache pode retornar a resposta credenciada.
5. O invasor pode ler o recurso personalizado usando um ataque Spectre.

O cache HTTP de um navegador da Web não permite que esse tipo de ataque aconteça na prática, mas há outros caches 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 somente pelo navegador

Muitas vezes, há várias camadas de cache. Alguns caches são dedicados a um único usuário, outros a vários usuários. Alguns são controlados pelo servidor, outros pelo usuário e outros por intermediários.

• Caches do navegador. Esses caches são de propriedade e dedicados a um único usuário, implementados no navegador da Web dele. Elas 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ários papéis.
• Cache / CDN do servidor de origem. 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 uma 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.

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

Muitos usuários usam proxies configurados localmente para fins de acesso (como compartilhamento de uma conexão limitada), inspeção de vírus ou prevenção de perda de dados (DLP). 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.

Em última análise, alguns recursos HTTPS podem ser armazenados em cache por esses proxies locais.

Como funciona o cache HTTP

• Por padrão, os recursos podem ser armazenados em cache implicitamente.
• 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 de Cookie.
• O cabeçalho Cache-Control oferece um controle mais refinado.

Realize estas ações recomendadas para seu site

Os desenvolvedores de sites de alto valor, que incluem sites com alto tráfego 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 que foi solicitada com cookies para uma solicitação que não foi realizada caso nenhuma ação preventiva tenha sido tomada.

Recomendamos que você siga uma destas etapas:

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

Mais especificamente, mude o comportamento padrão: sempre defina Cache-Control ou Vary.

Outras considerações

Há outros tipos semelhantes de ataques usando o cache HTTP, mas eles dependem de um mecanismo diferente do isolamento de origem cruzada. Por exemplo, Jake Archibald descreve alguns ataques em Como vencer no CORS.

Esses ataques são atenuados por alguns navegadores da Web que dividem o cache HTTP dependendo de a resposta do recurso ter sido solicitada com credenciais ou não. Desde 2022, o Firefox divide o cache, mas o Chrome e o Safari não. O Chrome pode dividir o cache no futuro. Esses ataques são diferentes e complementam a divisão deles por origem de nível superior.

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

---

Foto de capa de Ben Pattinson no Unsplash.