#30 Header Sobrescreve Identidade JWT — Resumo Executivo
Severidade: Alta O que é: Um atacante que possui um token de login válido para uma organização consegue forçar o sistema a acessar dados de outra organização apenas enviando um header com o nome dela. O sistema obedece o header e ignora a organização do token.
O Problema
O que o atacante consegue fazer
O que está em risco
Violação de isolamento entre organizações: o sistema é multi-tenant — cada organização tem seu banco de dados isolado. O header api-company-target decide qual banco acessar. Se o header vence o token, o isolamento é quebrado.
Por Que Isso Acontece
Analogia: porteiro conferindo crachá depois que a pessoa já entrou
Imagine um prédio com várias empresas. Cada visitante tem um crachá dizendo qual empresa ele pode acessar. Mas o porteiro fica no fim do corredor, não na entrada. Quando alguém chega e diz "quero ir para a sala da empresa Soma", o visitante já está dentro do prédio antes de o porteiro conferir o crachá.
É exatamente isso que acontece no sistema: a verificação de identidade (ler o token JWT) está configurada DEPOIS do ponto onde o request já foi processado.
O que está errado no servidor
Por que o header vence o token
Quando o sistema funciona corretamente (por acidente)
Se o endpoint exige login ([Authorize]), o próprio mecanismo de permissão (passo 2 do pipeline) dispara a leitura do token sob demanda para decidir se autoriza ou não. Isso mascara o bug: parece que funciona, mas é um efeito colateral.
Quando não funciona: endpoints que NÃO exigem login — o token nunca é lido, e o header sempre vence.
A Solução
Mover a verificação de identidade para ANTES do processamento do request. É como colocar o porteiro na entrada do prédio, onde ele deveria estar.
É uma correção de uma linha por serviço no arquivo de configuração. Nenhuma lógica de negócio é alterada.
Antes e Depois
Como a organização passa a ser definida
Relação com outros cards
| Card | O que faz | Sem ele |
|---|---|---|
| #08 | Tranca a porta: endpoints de pagamento passam a exigir login | Atacante anônimo acessa dados de fraude |
| #30 (este) | Lê o crachá: organização do JWT passa a valer mais que o header | Mesmo logado, atacante acessa dados de outra organização |
| #07 | Reforça a porta: valida que o header tem formato correto | Header malicioso poderia injetar comandos SQL |
Juntos, os três cards fecham as vulnerabilidades de acesso entre organizações: #08 garante que só usuários logados entram, #30 garante que cada um só acessa a própria organização, #07 garante que ninguém injeta comandos pelo header.
Escopo da correção
| Serviço | O que contém |
|---|---|
| Checkout (pagamentos) | Endpoints de fraude e pagamento testados no pentest |
| Cart (carrinho) | Mesmo padrão de configuração do checkout |
| Product (produtos) | Mesmo padrão de configuração do checkout |
| Store (lojas) | Mesmo padrão de configuração do checkout |
Os demais ~13 serviços têm o mesmo bug de configuração, mas não foram testados no pentest. Serão corrigidos em lote futuro.
Verificação de Segurança
O Que NÃO Entra Neste Fix
| Item | Motivo | Quando |
|---|---|---|
| Corrigir os ~13 serviços restantes | Pentest testou apenas 4 | Card futuro em lote |
Remover uso do header api-company-target | Requer refatoração ampla em 10+ serviços e mudança no app | Fora do escopo |
| Endpoints públicos (ecommerce) | Cliente final da loja virtual não tem login — não usa JWT | Card separado |
| Webhooks de pagamento (Braspag, ClearSale) | Chamados por sistemas externos, sem JWT | Card separado |
| SignalR hub auth | Mesma causa raiz, endpoint diferente | Card #29 |
Impacto
- Vendedores e portal: nenhum impacto. O app e portal já enviam o token de login em todas as requisições. A correção é invisível para o usuário.
- Clientes: nenhum impacto. O comportamento do sistema não muda para uso legítimo.
- Segurança: fecha a vulnerabilidade de um usuário autenticado conseguir acessar dados de outra organização alterando um header. O token de login passa a ser a fonte de verdade para definir a organização do usuário.
- Risco de regressão: mínimo. Apenas 4 serviços afetados, mesma alteração em todos (uma linha). Pipeline resultante segue exatamente a ordem recomendada pela Microsoft.