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.