• +55 61 98170-3055
  • contato@securitylabs.com.br
  • CLN Qd. 305, Bl C, N° 34 - 1° andar, CEP: 70.737-530 Brasília/DF
  • News

    Os 10 principais riscos de segurança da API OWASP: autorização de nível de função quebrada

    O número cinco na lista dos  10 principais riscos de segurança de API do Open Worldwide Application Security Project® (OWASP)  é a autorização de nível de função quebrada.

    A autorização de nível funcional quebrada (BFLA) ocorre quando os terminais são expostos a usuários não autorizados.

    vetores de ataque

    Os invasores enviam chamadas de API legítimas para um endpoint que não deveriam poder acessar. Essas chamadas podem vir de usuários anônimos ou usuários comuns que não devem ter privilégios de acesso.

    Quando os endpoints são expostos, a exploração é fácil para os agentes de ameaças. Como as chamadas de API geralmente são estruturadas, os agentes de ameaças podem fazer pequenas modificações nas strings de maneira previsível. Esse ataque é semelhante às explorações de autorização em nível de objeto quebrado (BOLA) , mas, nesse caso, os invasores se concentram nas funções da API em vez dos objetos da API. Freqüentemente, ambos os tipos de ataques são usados ​​em combinação para sondar a segurança.

    Fraquezas de segurança

    A autorização implementada incorretamente ou mal configurada pode levar a falhas de segurança. Isso é surpreendentemente comum, pois os endpoints de API geralmente fazem parte de uma infraestrutura complexa e contêm um grande número de usuários, grupos e funções, incluindo usuários com várias funções. Os designs nativos da nuvem e a arquitetura de distribuição podem tornar isso especialmente complicado de gerenciar.

    Esses pontos fracos geralmente são fáceis de detectar por meio de uma avaliação cuidadosa dos privilégios de acesso, mas isso pode ser um desafio devido ao grande número de usuários e privilégios nos aplicativos.

    Impactos nos negócios

    Quando os invasores têm acesso irrestrito à funcionalidade da API, os impactos nos negócios podem ser graves. Isso pode levar à exposição de dados confidenciais, corrupção ou perda de dados ou interrupção do serviço. Por exemplo, os invasores podem acessar contas de usuários, criar ou excluir contas ou dados, assumir o controle de contas ou aumentar privilégios.

    Como funciona a autorização de nível de função quebrada

    A autorização no nível da função fornece controle granular de funções específicas em um aplicativo. Sem controles de acesso apropriados no nível da função, os dados podem ser expostos. Isso pode acontecer de várias formas, como:

    • Configurações incorretas no controle de acesso baseado em função (RBAC)
    • Erros de codificação, configurações incorretas ou falta de verificações de autorização para funções
    • Padrões excessivamente previsíveis, como IDs sequenciais ou padrões fáceis de adivinhar
    • Exposição de detalhes de implementação ou configuração, como chaves de banco de dados ou IDs

    Mais comumente, essas explorações ocorrem porque os endpoints da API são configurados para autenticar os usuários na conexão, mas depois que uma sessão é estabelecida, os endpoints não verificam se os usuários têm autorização para executar determinados comandos.

    Exemplos do mundo real

    Dois exemplos específicos do mundo real de exploits BFLA de 2022 mostram como isso pode ser potencialmente prejudicial.

    Informações pessoais de residentes do Texas de quase  dois milhões de reivindicações de seguro  foram expostas. A API do Departamento de Seguros do Texas (DPI) permitia o acesso a funções do aplicativo que deveriam estar protegidas. A falha passou despercebida por quase três anos e foi descoberta durante uma auditoria de gerenciamento de dados.

    Quase  10 milhões de registros de clientes foram comprometidos  em uma exploração de autorização de nível de função quebrada da Optus, a segunda maior empresa de telecomunicações da Austrália, no final de 2022. Os dados foram exfiltrados e a empresa foi atingida com pedidos de resgate para evitar a exposição.

    Detectando vulnerabilidades de autorização de nível de função quebrada

    Existem várias abordagens para detectar vulnerabilidades de autorização de nível de função quebrada, incluindo revisões manuais de código com foco em controles de acesso à API. Outros métodos incluem:

    • Teste de penetração, usando testes de penetração manuais ou automatizados para ataques semelhantes do mundo real para investigar vulnerabilidades em nível de função
    • Teste fuzz, que inclui testar endpoints de API usando entradas inesperadas ou inválidas ou usuários não autorizados
    • Revisão das funções e privilégios do usuário no nível da função

    Prevenção de vulnerabilidades de autorização de nível de função quebrada

    Parar o BFLA requer a implantação de verificações de autorização apropriadas. Por exemplo, um usuário regular pode acessar um terminal administrativo?

    Estratégias específicas incluem:

    Validação em nível de função

    Os usuários devem ter que limpar as verificações de autorização para cada função e não apenas no nível do aplicativo. Cada operação deve exigir autorização, impedindo que usuários não autorizados acessem as funções da API.

    Zero Trust Network Access (ZTNA)

    Em toda a infraestrutura, as organizações devem empregar práticas de confiança zero. Mesmo os usuários autorizados devem ser validados para cada ação de forma que, mesmo que os usuários tenham passado pela segurança do perímetro, eles ainda devem ser autorizados no nível da função.

    A confiança zero também incorpora o princípio do privilégio mínimo (PoLP) para conceder aos usuários o nível mínimo de acesso e privilégios necessários para concluir as funções autorizadas.

    Gerenciamento seguro de sessão

    O uso de tokens de sessão segura, limites de tempo de expiração e revogação de token no logout também podem ajudar a limitar o acesso não autorizado às funções da API.

    Monitoramento contínuo

    Ao comparar a atividade de linha de base com a atividade atual, o monitoramento pode verificar anomalias que possam indicar atividade suspeita e bloquear o acesso ou sinalizar para revisão. Por exemplo, chamadas rápidas de API para IDs sequenciais podem acionar avisos.

    Gerenciar todos os acessos administrativos

    Todos os controladores administrativos devem ter verificações de autorização separadas com base no grupo e na função do usuário. Também é importante separar os privilégios administrativos das funções gerais da API, impedindo o acesso no nível administrativo sem a devida autorização.

    Auditorias regulares de segurança

    Tal como acontece com outras explorações de API em potencial, auditorias e testes de segurança regulares podem ajudar a garantir que fortes controles de segurança e acesso estejam em vigor para impedir o acesso não autorizado aos terminais e funcionalidades da API.

    Leave a comment