Ir para o conteúdo

API2:2023 Broken Authentication

Agentes Ameaça/Vetores Ataque Falha Segurança Impactos
Específico da API : Abuso Fácil Prevalência Comum : Deteção Fácil Técnico Grave : Específico Negócio
O mecanismo de autenticação é um alvo fácil para os atacantes, uma vez que está exposto a todos. Embora possam ser necessárias competências técnicas mais avançadas para explorar alguns problemas de autenticação, geralmente existem ferramentas de exploração disponíveis. As conceções erradas dos engenheiros de software e de segurança sobre os limites da autenticação e a complexidade inerente da implementação tornam os problemas de autenticação prevalentes. Metodologias para detetar broken authentication estão disponíveis e são fáceis de criar. Os atacantes podem obter controlo total das contas de outros utilizadores no sistema, ler os seus dados pessoais e realizar ações sensíveis em seu nome. Os sistemas têm pouca probabilidade de conseguir distinguir as ações dos atacantes das ações legítimas dos utilizadores.

A API é vulnerável?

Os endpoints e fluxos de autenticação são ativos que carecem de proteção. Além disso, mecanismos de recuperação de password devem ser tratados da mesma forma que os mecanismos de autenticação.

Uma API é vulnerável se:

  • Permite ataques de credential stuffing, onde o atacante utiliza força bruta com uma lista de nomes de utilizador e palavras-passe válidos.
  • Permite ataques de força bruta a uma conta de utilizador específica, não implementando mecanismos de mitigação como captcha ou bloqueio da conta por excesso de tentativas de autenticação falhadas.
  • Permite a utilização de passwords fracas.
  • Envia informação de autenticação, tal como tokens e passwords, no URL.
  • Permite que os utilizadores alterem o seu endereço de email, password atual ou realizem outras operações sensíveis sem pedir a confirmação da password.
  • Não valida a autenticidade dos tokens de autenticação.
  • Aceita tokens JWT sem que estes sejam assinados/usando algoritmos fracos ("alg":"none")
  • Não valida a data de expiração dos tokens JWT.
  • Utiliza passwords em texto, não encriptadas, ou resumos fracos.
  • Utiliza chaves de encriptação fracas.

Além disso, um microsserviço é vulnerável se:

  • Outros microsserviços podem aceder a ele sem autenticação
  • Utiliza tokens fracos ou previsíveis para impor autenticação

Exemplos de Cenários de Ataque

Cenário #1

Para realizar a autenticação do utilizador, o cliente tem de enviar um pedido de API como o exemplo abaixo, com as credenciais do utilizador:

POST /graphql
{
  "query":"mutation {
    login (username:\"<username>\",password:\"<password>\") {
      token
    }
   }"
}

Se as credenciais forem válidas, é devolvido um token de autenticação que deve ser fornecido em pedidos subsequentes para identificar o utilizador. A quantidade de tentativas de login está sujeita a uma limitação temporal restritiva: apenas três pedidos são permitidos por minuto.

Para efetuar login por força bruta com a conta de uma vítima, os atores maliciosos aproveitam o agrupamento de consultas GraphQL para contornar a limitação temporal restritiva de pedidos, acelerando o ataque:

POST /graphql
[
  {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"},
  {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"},
  {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"},
  ...
  {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"},
]

Cenário #2

Para atualizar o endereço de email associado à conta de um utilizador, os clientes devem enviar um pedido API como o exemplo abaixo:

PUT /account
Authorization: Bearer <token>

{ "email": "<new_email_address>" }

Devido à API não exigir que os utilizadores confirmem a sua identidade fornecendo a sua password atual, atores maliciosos que consigam colocar-se numa posição de roubar o token de autenticação podem conseguir assumir a conta da vítima ao iniciar o processo de redefinição de senha após atualizar o endereço de email da conta da vítima.

Como Prevenir

  • Certifique-se de que conhece todos os fluxos de autenticação possíveis (e.g. móvel/web/deeplinks/etc.). Pergunte aos engenheiros responsáveis quais os fluxos em falta/não identificados.
  • Leia sobre os mecanismos de autenticação em uso. Certifique-se que compreende quais e como são usados. OAuth não é um mecanismo de autenticação, assim como também não o são as API keys.
  • Não reinvente a roda em termos de autenticação, geração de tokens, armazenamento de passwords. Opte pela utilização de standards.
  • Endpoints para recuperação de password devem ser tratados como os endpoints de login no que diz respeito à proteção contra ataques de força bruta, limitação do número de pedidos e bloqueio de conta.
  • Exija nova autenticação para operações sensíveis (e.g. alterar o endereço de email do proprietário da conta/número de telefone para autenticação de dois fatores).
  • Utilize a OWASP Authentication Cheatsheet.
  • Sempre que possível implemente autenticação de múltiplos fatores.
  • Implemente mecanismos anti-força bruta para mitigar ataques do tipo credential stuffing, dicionário e força bruta nos endpoints de autenticação. Este mecanismo deve ter configurações mais restritivas do que para os demais endpoints da API.
  • Implemente mecanismos de bloqueio de conta / captcha para prevenir ataques de força bruta contra utilizadores específicos. Implemente verificação da qualidade/força das passwords.
  • As API keys não devem ser usadas para autenticação dos utilizadores. Apenas devem ser usadas para autenticação dos clientes da API.

Referências

OWASP

Externas