01 - STAKEHOLDER (quem valida e esclarece):
02 - USUÁRIO ou PAPEL (quem é afetado):
03 - COMPORTAMENTO ATUAL (descreva o erro identificado):
04 - IMPACTO (descreva a consequência do erro):
05 - PASSOS PARA REPRODUZIR (descreva como chegar até o erro):
06 - EVIDÊNCIAS (acrescente capturas de tela, links para logs ou arquivos relevantes):
07 - COMPORTAMENTO ESPERADO (descreva como o cenário deveria se comportar sem o erro em questão):

01 - STAKEHOLDER (quem valida e esclarece):

@MARCOS STUMPF @Robson Thanael Poffo

02 - PROBLEMA (cenário e/ou dor):

Durante os testes, identificamos que a aplicação está configurada de forma a aceitar requisições CORS (Cross-Origin Resource Sharing) de qualquer origem. Ao modificar o cabeçalho Origin em uma requisição e utilizar uma URL arbitrária, o servidor aceitou a origem sem aplicar restrições.

Para reproduzir a vulnerabilidade, realizamos o envio de um convite para participar da plataforma, com a requisição sendo interceptada por meio do proxy Burp Suite, possibilitando a análise detalhada do tráfego e da funcionalidade do processo.

Referência na página 81: https://drive.google.com/file/d/1wS04S0cW0MyEseZQVEj3E6N9Bn1V-3TN/view

Atualmente o regex abaixo parece não ser respeitado na Carol.

Sandbox: [\\w|\\.|-]*\\.qarol\\.ai([:|\\?|\\/].*)?$
Prod: [\\w|\\.|-]*\\.carol\\.ai([:|\\?|\\/].*)?$
Prefixo: (^|^[^:]+://|[^.]+.)

Recomendações
Restringir as origens aceitas pelo CORS apenas a domínios confiáveis e necessários para o funcionamento da aplicação. Além disso, evitar o uso de curingas em Access-Control-Allow-Origin e implementar controles adicionais de autenticação e autorização no backend.

Evidências da simulação

Embora as requisições estejam sendo aceitas com reposta 200 pelo servidor, o que é uma falha de configuração. Processos críticos como por exemplo, Esqueci minha Senha que envia um email com um link de redefinição não foi comprometida.

03 - OBJETIVO (solução proposta):

• Resolver a vulnerabilidade apontada no PENTEST.

04 - QUEM PODE USAR (perfis de usuários):

Tenant Users

05 - ASSETS (links e arquivos relevantes):

Não necessário, evidências no tópico 02.

06 - CRITÉRIOS DE ACEITE:

• ORG Admin deve ser ser capaz de informar o modo de aplicação de restrições CORS na Tenant:

  • As-is (retrocompatibilidade):

    • Obtém o origin do header do request e adiciona diretamente como Access-Control-Allow-Origin

    • O modo As-is não deve vir setado para novas tenants, e quando setado deve possuir indicador visual de configuração insegura.

  • Modo restritivo (padrão).

    • Somente aceitar origens no domínio Carol (*.carol.ai) e subdomínios explicitamente autorizados, utilizando comparação exata entre protocolo, domínio e porta, não sendo permitido matching parcial por contains ou regex permissivo, caso contrário, não retorna o cabeçalho Access-Control-Allow-Origin na resposta.

  • Com white-list:

    • O sistema deve permitir configuração de whitelist de origens permitidas por tenant.

      • Se não estiver na lista, não retorna o cabeçalho Access-Control-Allow-Origin na resposta, e bloqueia o processamento da requisição retornando 403 Forbidden.

      • A whitelist deve aceitar apenas URLs HTTPS válidas contendo protocolo, domínio e porta opcionais.

• Bloqueio de credentials inseguros:

  • Bloquear o uso de curingas em Access-Control-Allow-Origin em tempo de cadastro/configuração, quando Access-Control-Allow-Credentials=true.

• Suporte explícito a preflight:

  • Requisições HTTP OPTIONS (preflight) devem respeitar as mesmas validações de origem aplicadas às requisições principais.

  • As respostas preflight devem retornar apenas métodos e headers explicitamente autorizados.

• Normalização:

  • O sistema deve normalizar e validar origens utilizando parsing estruturado de URL da linguagem/framework oficial, prevenindo bypass por subdomínios maliciosos, punycode ou manipulação de strings.

• Auditoria:

  • Toda alteração na configuração CORS da tenant deve gerar log de auditoria contendo usuário responsável, data/hora e configuração alterada.