Relatório de pentest: um exemplo comentado

A seção de escopo protege as duas partes. Ela registra o que foi testado, o que não foi, e por quê. Sem isso, um incidente futuro em um componente nunca avaliado vira discussão sobre responsabilidade.

A seção também registra as limitações encontradas durante a execução: indisponibilidade do ambiente em determinada janela, funcionalidade bloqueada por proteção de borda que impediu teste completo, ou perfil de acesso que não foi entregue a tempo. Omitir limitação é o mesmo que declarar cobertura que não houve.

Este é o formato completo de um achado. Cada campo existe porque alguém precisa dele: o desenvolvedor precisa dos passos, o gestor precisa do impacto, o auditor precisa da referência e o reteste precisa do critério de verificação.

Identificador: ACH-001
Título: Quebra de autorização a nível de objeto na consulta de pedidos
Severidade: Crítica
Vetor CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (nota base 6.5)
Severidade final: Crítica (elevada pelo volume de dados pessoais expostos
  e pela exposição pública do endpoint)
Referência: OWASP API Security Top 10, API1:2023 Broken Object Level
  Authorization; OWASP WSTG-ATHZ-04
Componente: GET /v1/pedidos/{id} em api.exemplo.test
Perfil usado: cliente comum (conta de teste [email protected])

Descrição

O endpoint de consulta de pedido valida se o solicitante está autenticado, mas não verifica se o pedido consultado pertence à conta autenticada. Um cliente autenticado consegue recuperar o pedido de qualquer outro cliente informando o identificador correspondente. Os identificadores são numéricos e sequenciais, o que dispensa qualquer descoberta: basta decrementar o número do próprio pedido.

Passos de reprodução

• Autenticar na loja com a conta de teste [email protected] e obter o token de sessão
• Criar um pedido e anotar o identificador retornado, por exemplo 48213
• Repetir a consulta trocando o identificador por um valor menor, por exemplo 48212
• Observar que a resposta retorna 200 com o conteúdo do pedido de outra conta

GET /v1/pedidos/48212 HTTP/1.1
Host: api.exemplo.test
Authorization: Bearer <token da conta teste-a>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "pedido": 48212,
  "cliente": "M**** S****",
  "email": "m****@exemplo.test",
  "endereco": "Rua ****, 1**, São Paulo SP",
  "itens": [{ "sku": "SKU-8842", "qtd": 1 }],
  "total": 249.90
}

Impacto

Comprovado: um cliente autenticado acessa dados de pedido de outros clientes, incluindo nome, e-mail, endereço de entrega e itens comprados. Consequência plausível não testada: como os identificadores são sequenciais, a enumeração completa da base de pedidos é viável, o que caracterizaria tratamento indevido de dados pessoais em escala sob a LGPD. A enumeração em massa não foi executada, por decisão de limitar o impacto do teste.

Recomendação

• Validar no lado servidor, em cada endpoint que recebe identificador de objeto, se o recurso pertence à identidade autenticada
• Centralizar a verificação em uma camada comum, para que a regra não dependa de cada desenvolvedor lembrar de aplicá-la
• Substituir identificadores sequenciais por identificadores não previsíveis, como medida complementar e nunca como correção principal
• Registrar tentativa de acesso negado, para que a exploração futura seja detectável
• Verificar os demais endpoints que recebem identificador: a mesma ausência de validação costuma aparecer em vários

A terceira recomendação carrega uma armadilha frequente. Trocar identificador sequencial por identificador aleatório deixa a exploração mais difícil, não impossível, e várias equipes param aí. Sem validação de propriedade no servidor, a falha continua existindo para quem descobrir um identificador válido de qualquer outra forma.

Critério de reteste

O achado será considerado corrigido quando a requisição dos passos de reprodução retornar 403 ou 404 para pedido que não pertence à conta autenticada, e quando a mesma verificação passar em pelo menos três outros endpoints que recebem identificador de objeto.

Depois dos achados individuais, o relatório consolida. A tabela de consolidação é o documento que a equipe leva para o planejamento de sprint, e por isso ela precisa carregar prazo e responsável, não apenas severidade.

Uma observação que quase nunca aparece em modelo de relatório: achados de severidade média que se encadeiam merecem nota conjunta. No exemplo, a enumeração de usuário mais a política de senha fraca formam um caminho de ataque mais relevante do que qualquer um dos dois isoladamente.