Guia Completo para Segurança da API|5 Ameaças e Design Inquebrável Após a Autenticação

 

"É seguro porque estou autenticando com uma chave API ou token."
"Por ser uma API interna, não pode ser atacada de fora."
"Implementei a autenticação e vou cuidar de você do lado do app."

1. A autenticação é apenas o ponto de partida da segurança.
   Após passar na autenticação, saber quantas ameaças existem vai mudar sua percepção.

1. 5 Ameaças Após a Autenticação

Ameaça (1): Defeito de Autorização (BOLA/IDOR)

Esse é um problema em que o usuário autenticado A pode acessar os dados do usuário B.

Exemplos de quebra
GET /api/invoices/12345
O Usuário A pode receber a fatura do Usuário B apenas mudando o ID.
GET /api/invoices/12346

Contramedidas: Para cada solicitação, verifique do lado do servidor se esse usuário realmente pode acessar esse recurso.

Ameaça (2): Falta de limitação de taxa

Se você continuar enviando 10.000 solicitações por segundo para uma API autenticada:

• Serviço caído (DoS)
• A exploração de dados por força bruta é possível
• Explosão de custos (para APIs em nuvem)

Ameaça (3): Falta de Validação de Entrada

Se você confiar nos parâmetros de entrada da API e os passar diretamente para o banco de dados, isso se torna um terreno fértil para injeção SQL e injeção de comandos.

Ameaça (4): Vazamento de Resposta de Informações Sensíveis

JSON

Exemplo de quebra: retornando mais informações do que o necessário
{ 
  "user_id": "123", 
  "e-mail": "user@example.com", 
  "password_hash": "...", // Não
  "internal_role": "admin", // Não
  "api_key": "sk-..." // Absolutamente não é obrigatório
}

Ameaça (5): Falta de Registros de Auditoria

Se você não registrar quem, quando, qual API e com quais parâmetros, será impossível investigar após o incidente.

2. Design de Autorização: Sempre Valide Cada Solicitação

No topo da lista Top 10 de Segurança de APIs do OWASP está a Autorização em Nível de Objeto Quebrada (BOLA).

Pontos de design seguros:

• Use UUID em vez do número de série do DB para IDs de recursos (dificultando o palpite)
• Certifique-se de verificar se esse recurso pertence a esse usuário no lado do servidor antes de acessar
• Independente do framework e explicitamente implementado na camada de aplicação

3. Implementando a Limitação de Taxa

Basicamente, ele é implementado na camada API Gateway ou middleware.

Pontos de Design:

• Restringa tanto por usuário quanto por IP
• Se você ficar travado no limite, retorne '429 Muitas Solicitações' e especifique o motivo
• Os limites são definidos de acordo com a natureza da API (especialmente para APIs de autenticação)

4. Registros de Auditoria: O que Registrar

Itens mínimos a serem incluídos no registro de auditoria da API:

• Tempo de requisição, endpoint, método HTTP
• ID de usuário de autenticação
• Endereço IP do cliente
• Código de resposta
• Tamanho do corpo da solicitação (frequentemente excluindo o corpo principal)
• Tempo de processamento

Ao integrar isso com Sentinel e Splunk, é possível detectar anomalias na camada API.

5. Detecção de Anomalias: Como Usar APIs de Forma Diferente

Ele aprende padrões normais de uso da API e detecta desvios.

Exemplos de padrões anômalos:

• Um usuário específico envia continuamente um grande número de requisições GET no meio da noite
• Aumento repentino no acesso a endpoints que você normalmente não usa
• Acesso a API a partir de locais geograficamente não naturais

6. Aproximação da Segurança da Colorkrew

A Colorkrew Security oferece revisão de design e assistência na implementação para segurança de APIs.

**A segurança da API começa com a autenticação. **
Vamos criar juntos um "design inquebrável", desde autorização, limitação de taxa, logs de auditoria e detecção de anomalias.