Novo ataque de engano de cache explorações de falha entre cache e servidor da web

Um ataque de engano recém -documentado aproveita as incompatibilidades na normalização do caminho e no manuseio do delimitador entre camadas de cache e servidores de origem para expor pontos de extremidade sensíveis e roubar tokens de autenticação.

Os pesquisadores têm demonstrado Como as discrepâncias sutis no processamento de URL podem enganar uma rede de entrega de conteúdo (CDN) a recursos protegidos por cache – apenas para um invasor recuperá -los posteriormente, ignorando os controles de autenticação.

Compreendendo a vulnerabilidade

No coração deste ataque, há uma falta de comunicação entre o cache e o servidor de origem. As camadas de armazenamento em cache normalmente identificam ativos estáticos por extensão de arquivo ou prefixo de diretório, enquanto os servidores de origem aplicam o roteamento e o controle de acesso com base em caminhos normalizados.

Quando esses dois sistemas discordam de como interpretar um URL, as páginas sensíveis destinadas a permanecer não podem ser armazenadas em caches compartilhados. Um invasor pode buscar dados privados – como cookies de sessão ou tokens de API – sem sempre se autenticando.

Por exemplo, chat.openai[.]com/api/auth/session.css retorna um erro 400 e não está em cache, enquanto chat.openai[.]com/api/auth/session/test.css é bem -sucedido e é armazenado em cache porque aparece em um diretório de “compartilhamento”. Solicitando um caminho criado como:

https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123

O CDN vê como “compartilhar/…/api/auth/session” (assim armazenar em cache), mas o servidor de origem normaliza o caminho para “API/Auth/Session” e retorna o token da sessão.

Metodologia de ataque e mitigações

Os invasores devem primeiro identificar um diretório ou extensão que o cache trata como estático. Eles então criam URLs usando delimitadores ou seqüências de travessia que passam pelo cache inalteradas, mas são normalizadas pela origem. Técnicas comuns incluem:

• Discrepâncias de mapeamento de caminho: Anexando extensões falsas (por exemplo, .css, .js) a pontos de extremidade da API.
• Confusão do delimitador: usando caracteres como;,#ou barras codificadas (%2f) que o cache ignora, mas a origem processa.
• Explorações de normalização: combinando tokens de travessia (..) com separadores codificados, de modo que o cache mapeia para um caminho estático enquanto a origem resolve para um ponto de extremidade protegido.

Uma exploração bem -sucedida geralmente envolve três etapas:

1. Verifique o comportamento do cache de cache em um diretório estático conhecido.
2. Testes de travessia de caminho e manuseio de delimitador para confirmar a normalização diferencial.
3. Recupere o recurso sensível em cache, consultando o URL criado.

Para mitigar esses ataques, as organizações devem aplicar a normalização consistente de URL em todas as camadas e garantir que pontos de extremidade sensíveis nunca carregam cabeçalhos em cache. A configuração adequada das diretivas de controle de cache é fundamental:

Os desenvolvedores devem auditar regras da CDN para rejeitar solicitações contendo delimitadores inesperados ou sequências de travessia codificadas.

Além disso, os servidores de origem devem aplicar regras de roteamento estritas que ignorem os sufixos arbitrários-e retorne os cabeçalhos de controle de cache apropriados (por exemplo, sem lojas) em todos os terminais autenticados.

Testes regulares de cache-comportamento usando ferramentas como PortSwigger Os laboratórios podem ajudar a identificar as configurações incorretas antes de serem exploradas na natureza.

Ao alinhar interpretações de cache e origem dos URLs e marcar rigorosamente conteúdo privado como não cache, as organizações podem fechar este novo vetor para exposição a dados não autorizados.

Encontre esta notícia interessante! Siga -nosGoogle NewsAssim,LinkedIneXPara obter atualizações instantâneas!