FixVibe
Covered by FixVibehigh

Configuração incorreta de CORS: riscos de políticas excessivamente permissivas

O Compartilhamento de Recursos de Origem Cruzada (CORS) é um mecanismo de navegador projetado para relaxar a Política de Mesma Origem (SOP). Embora necessária para aplicativos da web modernos, a implementação inadequada – como ecoar o cabeçalho Origin do solicitante ou colocar a origem “nula” na lista de permissões – pode permitir que sites maliciosos exfiltrem dados privados do usuário.

CWE-942

Impacto

Um invasor pode roubar dados confidenciais e autenticados de usuários de um aplicativo vulnerável [S2]. Se um usuário visitar um site malicioso enquanto estiver conectado ao aplicativo vulnerável, o site malicioso poderá fazer solicitações de origem cruzada ao API do aplicativo e ler as respostas [S1][S2]. Isso pode levar ao roubo de informações privadas, incluindo perfis de usuário, tokens CSRF ou mensagens privadas [S2].

Causa Raiz

CORS é um mecanismo baseado em cabeçalho HTTP que permite aos servidores especificar quais origens (domínio, esquema ou porta) têm permissão para carregar recursos [S1]. As vulnerabilidades normalmente surgem quando a política CORS de um servidor é muito flexível ou mal implementada [S2]:

  • Cabeçalho de origem refletido: Alguns servidores leem o cabeçalho Origin de uma solicitação do cliente e o repetem no cabeçalho de resposta Access-Control-Allow-Origin (ACAO) [S2]. Isso permite efetivamente que qualquer site acesse o recurso [S2].
  • Cartões curinga mal configurados: Embora o curinga * permita que qualquer origem acesse um recurso, ele não pode ser usado para solicitações que exigem credenciais (como cookies ou cabeçalhos de autorização) [S3]. Os desenvolvedores geralmente tentam contornar isso gerando dinamicamente o cabeçalho ACAO com base na solicitação [S2].
  • Lista de permissões 'null': Alguns aplicativos colocam na lista de permissões a origem null, que pode ser acionada por solicitações redirecionadas ou arquivos locais, permitindo que sites maliciosos se disfarcem como uma origem null para obter acesso [S2][S3].
  • Erros de análise: Erros na correspondência de regex ou string ao validar o cabeçalho Origin podem permitir que invasores usem domínios como trusted-domain.com.attacker.com [S2].

É importante observar que CORS não é uma proteção contra falsificação de solicitação entre sites (CSRF) [S2].

Correções de concreto

  • Use uma lista de permissões estática: Evite gerar dinamicamente o cabeçalho Access-Control-Allow-Origin a partir do cabeçalho Origin da solicitação [S2]. Em vez disso, compare a origem da solicitação com uma lista codificada de domínios confiáveis ​​[S3].
  • Evite a origem 'nula': Nunca inclua null em sua lista de permissões de origens permitidas [S2].
  • Restringir credenciais: Defina Access-Control-Allow-Credentials: true somente se for absolutamente necessário para a interação de origem cruzada específica [S3].
  • Use a validação adequada: Se você precisar oferecer suporte a várias origens, certifique-se de que a lógica de validação do cabeçalho Origin seja robusta e não possa ser ignorada por subdomínios ou domínios de aparência semelhante [S2].

Como FixVibe testa isso

FixVibe agora inclui isso como uma verificação ativa bloqueada. Após a verificação do domínio, active.cors envia solicitações API de mesma origem com origem sintética do invasor e analisa os cabeçalhos de resposta CORS. Ele relata origens arbitrárias refletidas, CORS credenciado como curinga e CORS totalmente aberto em endpoints API não públicos, evitando ruído de ativos públicos.