0
0
As interfaces de programação de aplicativos (APIs) permitem que os desenvolvedores implementem serviços de forma rápida e fácil, mas também são igualmente atraentes para os atacantes. Isso ocorre porque eles podem fornecer acesso imediato a sistemas de back-end e conjuntos de dados confidenciais. O que torna esses ataques tão interessantes é como eles são executados: ao contrário de um “hack” tradicional, um ataque de API não depende de haver algo errado com a API. Em vez disso, os atacantes podem legitimamente usar a maneira como uma API funciona contra ela e podem simplesmente descobrir se ela não foi desenvolvida com segurança por meio de interação padrão.
A Fundação OWASP reconhece esse fato por meio da lista Top 10 de vulnerabilidades e riscos de segurança da API Security. Quando olhamos para a lista, existem seis métodos comuns de execução. Três dos problemas ocorrem devido à falta de controle de acesso e três ao abuso da lógica de negócios, com o restante existente devido ao gerenciamento insuficiente de tráfego, vulnerabilidades de aplicativos, falta de visibilidade e falta de prontidão operacional para a segurança.
Esses problemas são exclusivos das APIs e os tornam particularmente difíceis de proteger, então vamos olhar para cada um em detalhes.
1. Autorização de nível de objeto quebrado (BOLA)
Anteriormente conhecido como Referências de Objetos Diretos Inseguros (IDOR), o BOLA permite que o invasor execute uma ação não autorizada reutilizando um token de acesso. Este método tem sido amplamente utilizado para atacar dispositivos IoT, por exemplo, pois pode ser usado para permitir que o invasor acesse outras contas de usuário, altere as configurações e, geralmente, cause estragos muito para o constrangimento do fornecedor de IoT.
O ataque depende dos IDs de recursos ou objetos da API que não possuem medidas de validação suficientes em vigor. Em alguns casos, os dados usados pela API não têm validação do usuário e são acessíveis ao público, enquanto em outros casos as mensagens de erro retornam muitas informações, fornecendo ao invasor mais informações sobre como abusar da API.
Defender-se contra ataques BOLA requer a validação de todos os privilégios de usuário para todas as funções da API. A autorização da API deve ser bem definida na especificação da API e IDs aleatórios/impevisíveis. Também é importante testar esses métodos de validação de rotina.
2. Autenticação de usuário quebrada
Um invasor pode se passar por um usuário genuíno se houver falhas na autenticação do usuário. Mecanismos como login, registro e redefinição de senha podem ser bombardeados com ataques automatizados e, se mal protegidos, permitirão senhas fracas, retornarão mensagens de erro ao usuário com muitas informações, não terão validação de token ou criptografia fraca ou inexistente.
Prevenir esses abusos requer que a segurança seja priorizada durante o desenvolvimento. Todos os mecanismos de autenticação mencionados acima precisam ser identificados e a autenticação multifatorial (MFA) precisa ser aplicada. A equipe de desenvolvimento também deve procurar implementar mecanismos volumétricos e de proteção de bloqueio de contas para evitar ataques de força bruta.
3. Exposição excessiva de dados
Algumas APIs publicadas expõem mais dados do que o necessário, pois dependem do aplicativo cliente em vez de sistemas de back-end para filtrar. Os atacantes podem usar essas informações para realizar ataques de enumeração e construir uma compreensão do que funciona e do que não funciona, permitindo que eles criem um “livro de receitas” para roubar dados ou para orquestrar um grande ataque em um estágio posterior.
Limitar a exposição de dados requer que a empresa entenda e adapte a API às necessidades do usuário. O objetivo é fornecer a quantidade mínima de dados necessários, para que a API precise ser altamente seletiva nas propriedades que escolhe retornar. Informações confidenciais ou pessoalmente identificáveis (PII) devem ser classificadas em sistemas de back-end e a API nunca deve depender da filtragem do lado do cliente.
4. Falta de recursos e limitação de taxas
Se a API não aplicar limitação de taxa interna suficiente a parâmetros como tempos limite de resposta, memória, tamanho da carga útil, número de processos, registros e solicitações, os atacantes podem enviar várias solicitações de API criando um ataque de negação de serviço (DoS). Isso então sobrecarrega os sistemas de back-end, travando o aplicativo ou aumentando os custos de recursos.
A prevenção requer que limites de consumo de recursos da API sejam definidos. Isso significa definir limites para o número de chamadas de API e notificações do cliente, como redefinições e bloqueios. Lado do servidor, valide o tamanho da resposta em termos de número de registros e tolerâncias de consumo de recursos. Por fim, defina e aplique o tamanho máximo dos dados que a API suportará em todos os parâmetros e cargas úteis de entrada usando métricas como o comprimento das strings e o número de elementos da matriz.
5. Autorização de nível de função quebrada
Efetivamente, uma rotação diferente no BOLA, isso faz com que o atacante seja capaz de enviar solicitações para funções que eles não podem acessar. É efetivamente um escalonamento de privilégios porque as permissões de acesso não são aplicadas ou segregadas, permitindo que o invasor se faça passar por administrador, helpdesk ou um superusuário e execute comandos ou acesse funções confidenciais, abrindo caminho para a exfiltração de dados.
Parar essa atividade de salto de nível requer que o fluxo de trabalho de autenticação seja documentado e o acesso baseado em função seja aplicado. Isso requer um forte mecanismo de controle de acesso que flui de “pai para filho” e não permite o contrário.
6. Atribuição em massa
O invasor descobre parâmetros modificáveis e variáveis do lado do servidor que eles exploram criando novos usuários com privilégios elevados ou modificando perfis de usuário existentes. Isso pode ser evitado limitando ou evitando o uso de funções que vinculam entradas a objetos ou variáveis de código. O esquema da API deve incluir cargas úteis de dados de entrada e impor a segregação listando na lista de permissões as propriedades que podem ser descontadas pelo cliente e colocar na lista negra aquelas que devem ser restritas.
7. Configuração incorreta
Configurações padrão incompletas, ad hoc ou inseguras, cabeçalhos HTTP mal configurados, métodos HTTP desnecessários, compartilhamento permissivo de recursos de origem cruzada (CORS) e mensagens de erro detalhadas contendo informações confidenciais são, infelizmente, muito comuns nas APIs. Eles geralmente são o resultado de erro humano, devido à falta de endurecimento de aplicativos, práticas de patch pobres ou criptografia inadequada e, quando descobertos por um invasor, podem ser explorados, levando a fraudes e perda de dados.
A configuração tem tudo a ver com implementar as etapas certas durante o ciclo de vida da API, por isso é aconselhável implementar um processo de endurecimento repetível, um processo de revisão e atualização de configuração e avaliações regulares da eficácia das configurações. Definir e impor respostas (incluindo aquelas para erros) também pode impedir que as informações voltem para o invasor. As políticas CORS também devem ser implementadas para proteger implantações baseadas em navegador.
8. Injeção
Um item básico da lista dos 10 melhores aplicativos da Web OWASP, os ataques de injeção veem a injeção não confiável de código em solicitações de API para executar comandos ou obter acesso não autorizado a dados. Esses ataques podem acontecer quando o banco de dados ou aplicativo não tem filtragem ou validação de dados do cliente ou da máquina, permitindo que o invasor roube dados ou injete malware enviando consultas e comandos diretamente para o banco de dados ou aplicativo.
A mitigação de ataques de injeção requer separação entre dados/comandos e consultas. Os tipos de dados e padrões de parâmetros devem ser identificados, e o número de registros retornados deve ser limitado. Todos os dados de clientes e sistemas integrados externos devem ser validados, testados e filtrados.
9. Gerenciamento inadequado de ativos
APIs mal protegidas, como sombra, obsoletas ou no final da vida útil, são altamente suscetíveis a ataques. Outros vetores de ameaça incluem APIs de pré-produção que podem ter sido inadvertidamente expostas ao público, ou a falta de documentação da API que levou a uma falha exposta, como autenticação, erros, redirecionamentos, limitação de taxa, etc.
Aqui é fundamental analisar o processo de publicação da API, substituindo ou atualizando as análises de risco à medida que novas APIs são lançadas. Também é recomendado o monitoramento contínuo de todo o ambiente API, desde o desenvolvimento até o teste, estágio e produção, incluindo serviços e fluxo de dados. Adotar uma especificação OpenAPI pode ajudar a simplificar o processo.
10. Registro e monitoramento insuficientes
Os atacantes podem evitar completamente a detecção se a atividade da API não for registrada e monitorada. Exemplos de registro e monitoramento insuficientes incluem níveis de registro de API mal configurados, mensagens sem detalhes, integridade de log não garantida e APIs publicadas fora da infraestrutura de registro e monitoramento existente.
O registro e o monitoramento precisam capturar detalhes suficientes para descobrir atividades maliciosas, portanto, devem relatar tentativas de autenticação fracassadas, acesso negado e erros de validação de entrada. Um formato de log deve ser usado que seja compatível com ferramentas de segurança padrão e os dados de log da API devem ser tratados como confidenciais, seja em trânsito ou em repouso.
Desafios únicos
Todos os dez métodos de ataque revelam como pode ser difícil proteger APIs, que estão sendo continuamente giradas, atualizadas ou substituídas, às vezes diariamente. Na verdade, eles são tão numerosos que sua segurança só pode ser imposta usando automação. Consequentemente, muitas organizações tentaram usar soluções de segurança baseadas em regras e ferramentas de varredura de código, embora estas não estejam equipadas para detectar os tipos de abusos identificados na lista OWASP. Firewalls de aplicativos da Web (WAFs), por exemplo, oferecem proteção limitada porque procuram ameaças conhecidas, enquanto um gateway de API pode criar mais problemas atuando como um único ponto de falha.
É por essas razões que a Gartner criou recentemente uma categoria distinta de segurança de API, separada dessas outras ferramentas, em reconhecimento do fato de que as APIs têm seu próprio conjunto de problemas (que muitas vezes também são exclusivos do próprio negócio).
No relatório “Avance sua segurança de plataforma como serviço”, o analista Richard Bartley revela que as ferramentas de segurança da API para descoberta e proteção de API devem ser consideradas como tendo igual importância e entre a segurança de borda da Internet (ou seja, WAF) e as camadas de segurança do plano de dados (ou seja, a Plataforma de Proteção de Carga de Trabalho em Nuvem ou CWPP Esta nova geração de segurança de API é, portanto, nativa da nuvem e baseada em comportamento, permitindo que ela identifique e responda a atividades anômalas específicas da API.
Essas novas ferramentas se concentram especificamente na prevenção de ataques automatizados contra aplicativos voltados para o público e na persistência de erros de codificação da API. Eles usam aprendizado de máquina para analisar APIs e aplicativos da web, juntamente com análise comportamental, para determinar se a intenção por trás da interação da API é maliciosa ou benigna. Eles também podem agir bloqueando, limitando a taxa, geo-fencing e até enganando atacantes, ganhando tempo para responder. Tais recursos significam que soluções de segurança específicas da API podem ser aplicadas para ajudar o desenvolvedor e monitorar a segurança da API durante todo o seu ciclo de vida, evitando assim os ataques automatizados e explorações de vulnerabilidade identificados no Top 10 de Segurança da API OWASP.
Com as APIs continuando a superar os aplicativos da web na implantação de novos serviços, devemos atender à forma como eles são protegidos ou corremos o risco de construir esses serviços em bases instáveis. A esperança é que, com o Projeto OWASP destacando como as APIs podem ser exploradas e o Gartner criando uma nova categoria distinta, o setor de tecnologia finalmente perceba que a segurança das APIs é uma anomalia que merece sua própria solução.
FONTE: HELPNET SECURITY