A autenticação em APIs é um tópico complexo, com engenheiros de software e de segurança frequentemente tendo equívocos sobre quais são seus limites e como implementá-la corretamente. Para tornar as coisas ainda mais desafiadoras, solicitar credenciais e fatores de autenticação adicionais a usuários ou máquinas nem sempre é possível na comunicação direta via API, e os mecanismos de autenticação são alvos fáceis para atacantes, especialmente se estiverem totalmente expostos ou públicos. Esses dois pontos tornam o componente de autenticação potencialmente vulnerável a ataques avançados que incluem força bruta de autenticação, preenchimento de credenciais e quebra de credenciais.
Problemas com a autenticação em APIs geralmente decorrem de duas questões:
- Falta de mecanismos de proteção — Os endpoints de API responsáveis pela autenticação devem ser tratados de forma diferente dos endpoints comuns e possuir camadas extras de proteção.
- Implementação incorreta do mecanismo — O mecanismo é usado ou implementado sem considerar os vetores de ataque, ou o mecanismo não é apropriado para o caso de uso. Como exemplo, um mecanismo de autenticação projetado para dispositivos IoT normalmente não é a escolha certa para uma aplicação web como um site de eCommerce.
Existem também vários fatores técnicos que levam à autenticação quebrada em APIs. Estes são os mais comuns:
- Complexidade de senha fraca.
- Histórico de senhas curto ou inexistente.
- Limites de bloqueio de conta excessivamente altos ou ausentes.
- Falha ao provisionar certificados exclusivos por dispositivo na autenticação baseada em certificados.
- Durações excessivamente longas para rotações de senhas e certificados.
- Material de autenticação exposto em URLs e solicitações GET.
- Tokens de autenticação com entropia insuficiente.
- Uso de chaves de API como único material de autenticação.
- Falha ao validar a autenticidade do material de autenticação.
- Configuração insegura de JSON Web Token (JWT), como o uso de algoritmos de assinatura digital fracos ou falta de assinaturas.
- Uso de tamanhos de chave pequenos em algoritmos de criptografia ou hashing.
- Uso de cifras fracas ou quebradas.
- Uso de algoritmos inadequados para o caso de uso, como o uso de algoritmos de hash em vez de funções de derivação de chave baseadas em senha (PBKDF).
- Falha em elevar o nível de autenticação quando fluxos de autenticação estão sendo alvo de ataques, como solicitar dinamicamente um CAPTCHA ou um segundo fator de autenticação (2FA).
Impacto potencial de um ataque de autenticação quebrada
Um invasor que consiga explorar vulnerabilidades em mecanismos de autenticação pode assumir o controle de contas de usuários, obter acesso não autorizado aos dados de outro usuário ou realizar transações não autorizadas em nome de outro usuário.
As APIs podem ser projetadas explicitamente para comunicação entre máquinas ou comunicação direta via API. Um invasor que comprometa esse mecanismo de autenticação ou sessão autenticada pode potencialmente obter acesso a todos os dados aos quais aquela identidade de máquina tem direito. Existem também variantes desse tipo de ataque em projetos nativos da nuvem, com o comprometimento da autenticação de carga de trabalho e serviços de metadados de API no lado do servidor.
Como é um ataque de autenticação quebrada?
A autenticação quebrada é a segunda ameaça mais crítica à segurança de APIs listada no OWASP API Security Top 10. Exemplos comuns de ataques que visam a autenticação quebrada incluem enumeração de API e ataques de força bruta que realizam grandes volumes de solicitações de API com pequenas alterações. Esses ataques também podem visar uma autenticação quebrada ou fraca.
Como exemplo, os mecanismos de recuperação de senha geralmente enviam um SMS para o telefone do usuário com um token de redefinição composto por uma série de números. Um invasor pode iniciar uma redefinição de senha e, se a API não implementar limitação de taxa (rate limiting), o invasor pode enumerar (ou "adivinhar") o token de redefinição de senha até obter uma resposta bem-sucedida. Dependendo da capacidade de processamento do endpoint da API alvo, um invasor pode ser capaz de iterar por milhares ou milhões de combinações diferentes em poucos minutos.
Como exemplo, os mecanismos de recuperação de senha geralmente enviam um SMS para o telefone do usuário com um token de redefinição composto por uma série de números. Um invasor pode iniciar uma redefinição de senha e, se a API não implementar limitação de taxa (rate limiting), o invasor pode enumerar (ou "adivinhar") o token de redefinição de senha até obter uma resposta bem-sucedida. Dependendo da capacidade de processamento do endpoint da API alvo, um invasor pode ser capaz de iterar por milhares ou milhões de combinações diferentes em poucos minutos.
Exemplo do mundo real: O vazamento de dados do Parler
Em 2021, uma análise de Salt sobre o vazamento de dados do Parler constatou que a autenticação da plataforma de mídia social estava, pelo menos parcialmente, ausente, corroborando o consenso geral entre hacktivistas e veículos de mídia. Essa falha, juntamente com outras vulnerabilidades de segurança na plataforma Parler, permitiu a extração de pelo menos 70 TB de dados antes que a plataforma fosse desativada em 11 de janeiro de 2021, quando ficou claro que os participantes da invasão ao Capitólio, seis dias antes, a haviam utilizado para coordenar suas atividades.
Hacktivistas descobriram que pelo menos um endpoint de API estava disponível sem qualquer requisito de autenticação e várias APIs permitiam acesso direto às informações do perfil e ao conteúdo do usuário do Parler, incluindo postagens, imagens e vídeos. É improvável que o Parler tivesse a intenção ou configurado essas APIs e páginas para serem acessíveis sem autenticação.
Alguns relatórios indicaram que houve uma falha de configuração de segurança resultante de uma integração com o Twilio, que foi posteriormente desativada. Supostamente, alguns dos hacktivistas que participaram da extração de dados da plataforma usaram isso para contornar a autenticação multifator (MFA) durante a criação de contas e extrair dados. Isso foi posteriormente contestado pelos hacktivistas, e representantes do Twilio também declararam que a informação era falsa. Uma falha de configuração de MFA alimentaria ainda mais o debate sobre se os dados do Parler eram realmente públicos, mas não há evidências forenses suficientes para sustentar qualquer uma das alegações.
A maioria dos veículos de mídia considerou que os problemas de segurança do Parler foram resultado de uma codificação ruim. Embora escolhas de design e padrões de codificação inadequados provavelmente tenham desempenhado um papel, descartar os tipos de problemas que levaram à violação do Parler como simplesmente "codificação ruim" perpetua o atrito entre desenvolvedores, engenheiros e profissionais de segurança.
O desenvolvimento moderno de aplicações e o design de sistemas são incrivelmente complexos e exigem que muitos indivíduos, tanto em funções de segurança quanto em funções que não são de segurança, trabalhem em sincronia para que uma aplicação de grande escala funcione sem problemas. O problema é agravado quando se considera a cadeia de suprimentos digital moderna e como as organizações terceirizam elementos de TI no atacado ou por projeto. Bugs e vulnerabilidades são inevitáveis. No entanto, podemos continuar a aprender com esses erros para melhorar o estado da segurança de aplicações e da segurança de APIs.
Por que as ferramentas existentes falham ao proteger APIs contra autenticação quebrada
Controles de segurança tradicionais, como WAFs, normalmente não aplicam a autenticação em um nível granular e podem apenas verificar a presença de um identificador de sessão ou token de autenticação em uma determinada solicitação. Gateways de API podem aplicar a autenticação como parte das políticas de controle de acesso de gerenciamento de API, mas isso pressupõe que as equipes responsáveis definiram a política adequadamente.
Frequentemente, existe uma falha operacional entre as equipes que criam APIs, as equipes que publicam APIs e as equipes que protegem APIs. Ainda assim, os gateways de API não entendem qual autenticação é adequada para uma API em um determinado caso de uso.
Os controles de segurança tradicionais também carecem de recursos para rastrear o tráfego de ataque ao longo do tempo, o que é necessário para decifrar as diferentes formas de ataques avançados direcionados à autenticação, como credential stuffing e quebra de credenciais. Eles geralmente dependem de taxas excessivas de consumo de API para identificar tentativas básicas de ataques de força bruta.
Como proteger suas APIs contra ataques de autenticação quebrada
Para se proteger contra ataques de autenticação quebrada, uma solução de segurança de API deve ser capaz de traçar o perfil da sequência de autenticação típica para cada fluxo de API. A solução pode então detectar comportamentos anormais, como credenciais ausentes, fatores de autenticação ausentes ou chamadas de autenticação fora de sequência. Determinar a linha de base e identificar comportamentos anormais só pode ser feito analisando grandes quantidades de tráfego de API em produção. Essa forma de análise é fundamental para mitigar ataques avançados que visam a autenticação, como credential stuffing e quebra de credenciais.
Para saber mais sobre como a Salt pode ajudar a defender sua organização contra riscos de API, você pode falar com um representante ou agendar uma demonstração personalizada.