Testando a Segurança de APIs

Quando Usar

• Testar endpoints de API para falhas de autorização, vulnerabilidades de injeção e bypass de lógica de negócios
• Avaliar a segurança da arquitetura de microsserviços onde APIs são o principal método de comunicação
• Validar se as proteções do gateway de API (limitação de taxa, autenticação, validação de entrada) estão sendo aplicadas corretamente
• Testar integrações de API de terceiros para exposição de dados e configurações inseguras
• Avaliar APIs GraphQL para divulgação de introspecção, ataques de complexidade de consulta e bypass de autorização

Não use contra APIs sem autorização escrita, para testes de carga ou testes de negação de serviço, a menos que explicitamente escopo, ou para testar APIs de produção que processam transações financeiras reais sem salvaguardas.

Pré-requisitos

• Documentação da API (OpenAPI/Swagger, esquema GraphQL, coleção Postman) ou acesso à aplicação para engenharia reversa da API
• Burp Suite Professional configurado para interceptar tráfego de API com tratamento de tipo de conteúdo JSON/XML
• Postman ou Insomnia para organizar e reenviar requisições de API em diferentes contextos de autenticação
• Tokens de API ou credenciais válidas em múltiplos níveis de privilégio (não autenticado, usuário padrão, administrador)
• URL base da API alvo e informações de versão

Fluxo de Trabalho

Etapa 1: Descoberta e Documentação da API

Mapeie a superfície completa de ataque da API:

• Importar documentação da API: Carregue especificações OpenAPI/Swagger no Postman ou Burp Suite para catalogar todos os endpoints, métodos, parâmetros e requisitos de autenticação
• Engenharia reversa de APIs não documentadas: Proxy o aplicativo móvel ou frontend web através do Burp Suite e exercite todos os recursos para capturar chamadas de API. Exporte o sitemap do Burp como o inventário de endpoints base.
• Introspecção GraphQL: Envie uma consulta de introspecção para descobrir o esquema completo:

  {"query": "{__schema{types{name,fields{name,args{name,type{name}}}}}}"}
  

• Enumeração de endpoints: Use fuzzing para encontrar versões ocultas da API (/api/v1/, /api/v2/, /api/internal/), endpoints de depuração (/api/debug, /api/health, /api/metrics) e endpoints administrativos
• Documentar mecanismos de autenticação: Identifique se a API usa chaves de API, tokens Bearer OAuth 2.0, JWT, cookies de sessão ou TLS mútua

Etapa 2: Teste de Autenticação e Tokens

Teste mecanismos de autenticação para fraquezas:

• Análise JWT: Decodifique o JWT e inspecione as claims (sub, exp, iss, aud, role). Teste:
  • Confusão de algoritmo: Mude alg para none e remova a assinatura
  • Confusão de chave: Mude alg de RS256 para HS256 e assine com a chave pública
  • Segredo fraco: Brute-force o segredo HMAC com hashcat -m 16500 jwt.txt wordlist.txt
  • Expiração do token: Verifique se os tokens expiram e não podem ser usados após a expiração
  • Manipulação de claims: Modifique as claims de role, userId ou permission e re-assine
• Teste OAuth 2.0: Verifique manipulação de redirect_uri, reutilização de código de autorização, vazamento de token em cabeçalhos Referer e ausência do parâmetro state (CSRF)
• Segurança de chave de API: Teste se as chaves de API são validadas por endpoint, se chaves revogadas são imediatamente rejeitadas e se chaves em strings de consulta aparecem em logs de acesso ou análises

Etapa 3: Teste de Autorização (BOLA/BFLA)

Teste para Autorização Quebrada no Nível do Objeto (BOLA) e Autorização Quebrada no Nível da Função (BFLA):

• Teste BOLA (IDOR): Para cada endpoint que retorna dados específicos do usuário, substitua o identificador do objeto pelo identificador de outro usuário:
  • GET /api/users/123/orders -> GET /api/users/456/orders
  • Teste com IDs numéricos, UUIDs, nomes de usuário e endereços de e-mail
  • Automatize com a extensão Burp Autorize: configure-a com duas sessões (atacante e vítima) e reenvie todas as requisições
• Teste BFLA: Usando um token de baixo privilégio, tente acessar endpoints administrativos:
  • DELETE /api/users/456 (exclusão apenas para administradores)
  • PUT /api/users/456/role (modificação de role)
  • GET /api/admin/dashboard (dados do painel de administração)
• Atribuição em massa: Envie propriedades JSON adicionais não mostradas na documentação:

  PUT /api/users/123
  {"name": "Test", "role": "admin", "isVerified": true, "balance": 99999}
  

• Teste de métodos HTTP: Se GET funcionar em um endpoint, tente PUT, PATCH, DELETE e OPTIONS para descobrir métodos desprotegidos

Etapa 4: Validação de Entrada e Teste de Injeção

Teste entradas de API para falhas de injeção e validação:

…