O aspeto do nosso relatório de avaliação
Um excerto ilustrativo e expurgado da entrega que recebe no final de um projeto. Cada achado abaixo é sintético e corresponde a um alvo fictício. Aqui não constam dados reais de clientes.
- Projeto
- Teste de intrusão de aplicação web e API
- Alvo
- Acme Cloud Platform (ilustrativo)
- Janela de avaliação
- Um projeto de duas semanas (prazo relativo, sem datas fixas)
- Classificação
- Confidencial (exemplo ilustrativo)
- Versão do relatório
- Exemplo v1.0
Resumo executivo
A Vexaro avaliou a aplicação web acessível a partir do exterior e a API de suporte da Acme Cloud Platform ao longo de um projeto grey-box de duas semanas. Os testes seguiram o OWASP Web Security Testing Guide e foram verificados manualmente, para além das ferramentas automatizadas.
Postura de risco global: elevada. A aplicação aplica corretamente a autenticação e a segurança do transporte, mas a autorização ao nível do objeto é aplicada de forma inconsistente. Dois achados são exploráveis individualmente: uma referência direta a objeto insegura (IDOR) na API de faturação e uma falsificação de pedidos do lado do servidor (SSRF) na funcionalidade de importação de documentos. Encadeados, permitiriam a um utilizador autenticado com poucos privilégios ler as faturas de outros inquilinos e alcançar os metadados internos da cloud. Reforçar a camada de controlo de acesso e restringir os pedidos de saída resolve a maior parte do risco residual.
8 achados pontuados com CVSS 3.1
Âmbito e metodologia
O projeto abrangeu a aplicação web em produção, a sua API REST, a conta de cloud que as aloja e o perímetro de rede acessível a partir do exterior. Os testes foram limitados no tempo e realizados a partir de uma conta autenticada com poucos privilégios e de uma linha de base não autenticada.
- Aplicação web: app.acme.example (fluxos autenticados e anónimos)
- API REST: api.acme.example (endpoints v1 e v2)
- Conta de cloud: armazenamento de objetos, metadados de computação e revisão de IAM
- Perímetro de rede externo: serviços expostos e configuração de TLS
- Negação de serviço e testes de carga volumétrica
- Engenharia social e acesso físico
- SaaS de terceiros não operado pelo alvo
Metodologia e referências
Os testes foram primeiro manuais e mapeados para referenciais reconhecidos do setor, para que os achados sejam reproduzíveis e a cobertura auditável.
Web Security Testing Guide: os casos de teste que orientam a cobertura da aplicação.
Application Security Verification Standard: a base de verificação ao nível dos controlos.
Táticas e técnicas de adversários usadas para enquadrar caminhos de ataque realistas.
Penetration Testing Execution Standard: o processo global do projeto.
Cada achado é pontuado com CVSS 3.1 e traduzido numa classificação de risco de negócio. A severidade reflete a explorabilidade e o impacto no contexto deste ambiente, e não apenas a pontuação base.
Achados
Oito achados representativos do projeto, ordenados por severidade. O primeiro é desenvolvido na íntegra abaixo, para mostrar o nível de detalhe de cada entrada do relatório.
| ID | Achado | Severidade | CVSS | Estado |
|---|---|---|---|---|
| ACME-2024-001 | IDOR na API de faturação expõe faturas de outros inquilinos | Alta | 8.1 | Aberto |
| ACME-2024-002 | Server-side request forgery na importação de documentos | Alta | 7.7 | Aberto |
| ACME-2024-003 | Autorização ao nível das funções quebrada em endpoints de administração | Média | 6.5 | Corrigido e reavaliado |
| ACME-2024-004 | Stored XSS no campo de assunto do ticket de suporte | Média | 5.4 | Aberto |
| ACME-2024-005 | Política de palavras-passe fraca permite credenciais triviais | Baixa | 3.7 | Aberto |
| ACME-2024-006 | Erros detalhados da API expõem stack traces e versões de bibliotecas | Baixa | 3.1 | Risco aceite |
| ACME-2024-007 | Cabeçalhos de segurança em falta (HSTS, CSP, frame-ancestors) | Info | 2.4 | Corrigido e reavaliado |
| ACME-2024-008 | Cookie de sessão emitido sem o atributo Secure | Info | 2.0 | Aberto |
Achado de exemplo em detalhe completo
Um achado, desenvolvido com a profundidade que cada entrada recebe num relatório real: descrição, impacto, evidência, reprodução, remediação e referências.
IDOR na API de faturação expõe faturas de outros inquilinos
- ID do achado
- ACME-2024-001
- CVSS 3.1
- 8.1 (Alta)
- Vetor
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- CWE
- CWE-639: Authorization Bypass Through User-Controlled Key
Descrição
A API de faturação devolve documentos de fatura através de um identificador numérico sequencial fornecido no caminho do pedido. O endpoint autentica quem faz o pedido, mas nunca verifica se a fatura solicitada pertence ao inquilino de quem chama. Por conseguinte, qualquer utilizador autenticado pode enumerar o identificador e obter faturas pertencentes a outras organizações, incluindo nomes de contactos de faturação, montantes e linhas de detalhe.
Impacto
Trata-se de uma violação de confidencialidade entre inquilinos. Um utilizador autenticado com poucos privilégios de qualquer inquilino consegue ler os registos financeiros de todos os outros inquilinos incrementando um único número inteiro. Os dados expostos incluem condições comerciais e dados de contacto pessoais, criando uma exposição tanto de privacidade como de inteligência concorrencial. Como os identificadores são sequenciais, todo o conjunto de faturas pode ser recolhido de forma programática em minutos.
Evidência
Pedido e resposta ilustrativos. O anfitrião, o token e os valores são sintéticos e estão expurgados.
GET /v2/invoices/10428 HTTP/1.1
Host: api.acme.example
Authorization: Bearer eyJhbGciOi...REDACTED.SAMPLE.TOKEN
Accept: application/jsonHTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 10428,
"tenant_id": 3304,
"bill_to": "[REDACTED], Northwind Trading",
"amount_due": "14,920.00 USD",
"status": "unpaid"
}'Passos para reproduzir
- 1Autentique-se na aplicação com qualquer conta válida de poucos privilégios e capture o token bearer.
- 2Solicite a sua própria fatura, p. ex. GET /v2/invoices/10427, e confirme uma resposta 200.
- 3Diminua ou aumente o identificador numérico (.../10428, .../10429) e repita o pedido com o seu próprio token.
- 4Observe que são devolvidas faturas pertencentes a outros valores de tenant_id, confirmando a ausência da verificação de autorização ao nível do objeto.
Remediação
Imponha autorização ao nível do objeto em cada pedido: resolva a fatura e, em seguida, confirme que o seu tenant_id corresponde ao do principal autenticado antes de devolver quaisquer dados; caso contrário, responda 404. Aplique a verificação de forma centralizada (por exemplo, numa camada de política ou no âmbito da consulta) em vez de por handler, e acrescente um teste de regressão que garanta que um pedido entre inquilinos é rejeitado. Substituir os identificadores sequenciais por outros não adivinháveis reduz a enumeração, mas é defesa em profundidade e não um substituto da verificação de autorização.