Teste de intrusão de API
As APIs falham mais frequentemente na autorização, e essas falhas não se encontram com um único token. Testamos as suas APIs REST e GraphQL em várias funções e inquilinos, mapeadas ao OWASP API Security Top 10, para encontrar as lacunas de controlo de acessos ao nível do objeto e da função que realmente importam.
O que testamos
O âmbito assenta no OWASP API Security Top 10 (2023). O trabalho que mais resultados dá, e que mais vezes fica por fazer, é o teste autenticado com várias funções e inquilinos: é a única forma de encontrar autorização quebrada ao nível do objeto e da função. Pedimos a sua especificação OpenAPI/Swagger para cobrir quase todas as rotas (se não existir, isso já é um achado).
- Broken Object Level Authorization (BOLA / IDOR) entre inquilinos e funções
- Broken Function Level Authorization (BFLA) através de trocas de função e de método
- Autorização quebrada ao nível das propriedades de objeto: mass assignment e exposição excessiva de dados
- Autenticação, consumo de recursos sem restrições e fluxos de negócio sensíveis
- Injeção, SSRF e configuração de segurança incorreta
- Especificidades de GraphQL: introspeção, batching, DoS por consultas aninhadas e divulgação de erros
Grey-box, autenticado, com várias funções
O grey-box é a opção com melhor relação custo-benefício: fornece a especificação e contas de teste para cada função. Trabalhamos sobretudo à mão, porque os scanners apanham configurações incorretas e CVE conhecidos, mas não detetam as falhas de autorização e de lógica de negócio que concentram o risco das APIs.
- 1
Definição do âmbito e contas
Acordamos os limites e recolhemos várias contas em diferentes funções e inquilinos, além da sua especificação OpenAPI/Swagger.
- 2
Inventário de endpoints
A partir da especificação e do tráfego real, construímos um mapa completo de rotas e operações e sinalizamos as lacunas na especificação.
- 3
Sondagem de autenticação e autorização
Testamos o controlo de acessos ao nível do objeto e da função com várias funções e inquilinos. É aqui que está o cerne do risco das APIs.
- 4
Entradas, injeção e abuso de lógica de negócio
Testamos injeção, SSRF, consumo de recursos e abuso de fluxos de negócio sensíveis com prova de conceito.
- 5
Relatório e reteste gratuito
Recebe um relatório priorizado com evidências de pedido/resposta; voltamos a testar os problemas corrigidos sem custos adicionais, dentro do prazo fixado no SoW.
O que recebe
A mesma profundidade do nosso relatório de exemplo, cujo achado desenvolvido é precisamente um IDOR entre inquilinos numa API (CWE-639, CVSS 3.1). Cada achado inclui a evidência necessária para o reproduzir e corrigir.
- Resumo executivo e postura de risco global
- Cada achado: descrição, impacto, evidência, passos para reproduzir e remediação
- Prova de conceito como pares de pedido/resposta
- Severidade pontuada com CVSS 3.1 e traduzida em risco de negócio
- Referências ao OWASP API Security Top 10 (2023) e ao CWE
- Reteste gratuito dos problemas remediados dentro do prazo fixado no SoW
Assente nos padrões OWASP API Security
A cobertura segue o OWASP API Security Top 10 (2023); o teste de GraphQL segue ainda o OWASP WSTG-APIT-01 (Testing GraphQL). Os achados de autorização (BOLA, BFLA, propriedades de objeto) exigem várias contas com diferentes funções e inquilinos: com um único token não se encontram. Os achados são pontuados com CVSS 3.1.