Falhas de autorização são frequentemente o resultado de autorização implementada incorretamente ou mal configurada. Implementar mecanismos de autorização adequados é uma tarefa complexa, já que aplicações modernas podem conter muitos tipos de papéis, grupos e hierarquia de usuários, como subusuários e usuários com mais de um papel. Isso é ainda mais complicado com arquiteturas de aplicação distribuídas e design nativo da nuvem. A autorização de nível de função quebrada (BFLA) compartilha algumas semelhanças com a autorização de nível de objeto quebrada (BOLA) a esse respeito.
Atacantes podem descobrir essas falhas em APIs porque as chamadas de API são estruturadas e previsíveis, mesmo em designs REST. Isso pode ser feito na ausência de documentação de API ou definições de esquema, através de engenharia reversa de código do lado do cliente e interceptação de tráfego de aplicação. Alguns endpoints de API também podem ser expostos a usuários comuns, não privilegiados, tornando-os mais fáceis de serem descobertos por atacantes.
Essas falhas podem ser exploradas ao enviar requisições de API legítimas para um endpoint de API ao qual os atacantes não deveriam ter acesso, ou ao interceptar e manipular requisições de API originadas de aplicações cliente. Por exemplo, um atacante poderia mudar um método HTTP de GET para PUT. Alternativamente, o atacante também poderia alterar um parâmetro de consulta ou uma variável do corpo da mensagem, como mudar a string “users” para "admins" em uma requisição de API.
Qual é a diferença entre BOLA e BFLA?
A autorização de nível de função quebrada (BFLA) pode ser considerada uma versão de nível superior da autorização de nível de objeto quebrada (BOLA). A principal diferença é que, ao explorar uma vulnerabilidade BFLA, um atacante foca em funções gerais da API em vez de objetos individuais da API. A consequência da BFLA é que os clientes podem acessar funcionalidades além do seu nível de acesso pretendido, como funções administrativas.
Atacantes tentarão explorar ambas as vulnerabilidades ao visar APIs a fim de escalar privilégios horizontalmente ou verticalmente.
Impacto Potencial de um Ataque de Autorização de Nível de Função Quebrada
A autorização de nível de função quebrada (BFLA) foi identificada como a quinta ameaça mais crítica às APIs no OWASP API Security Top 10, e com razão. De fato, atacantes que exploram vulnerabilidades de autorização de nível de função quebrada podem obter acesso a recursos não autorizados, assumir o controle da conta de outro usuário, criar/excluir contas, ou escalar privilégios para obter acesso administrativo.
Baixe o eBook OWASP API Security Top 10 hoje
Como é um Ataque BFLA?
Exemplo do Mundo Real: New Relic Synthetics
Em 2018, o pesquisador de segurança cibernética Jon Bottarini descobriu que um usuário restrito poderia fazer alterações em alertas no New Relic Synthetics monitores sem as permissões adequadas para fazê-lo. Na verdade, eles poderiam fazer alterações sem permissão alguma devido à fraqueza de escalonamento de privilégios presente no produto na época. A exploração envolvia o envio de uma solicitação legítima a um endpoint de API que, de outra forma, não seria visível para o usuário restrito.
Como parte de sua pesquisa de segurança, Bottarini capturou o tráfego de uma sessão privilegiada usando uma ferramenta de proxy interceptador, o Portswigger Burp Suite. Esse tráfego incluía uma solicitação POST para um endpoint e função de API que cria alertas em monitores Synthetics. Ele descobriu que era possível interceptar uma solicitação GET da sessão não privilegiada, reter os tokens e cookies para aquele usuário restrito e alterar o restante da solicitação interceptada para se assemelhar à solicitação POST privilegiada. Essa manipulação do tráfego da API para acessar funcionalidades não visíveis na interface do usuário (totalmente ou para aquele usuário e suas permissões) é uma técnica comum que os invasores usam para explorar fraquezas de autorização em nível de função e escalar privilégios.
Por que as Ferramentas Existentes Falham em Proteger suas APIs Contra BFLA
Controles de segurança tradicionais como WAFs e gateways de API carecem do contexto da atividade da API e, portanto, não sabem que o invasor no primeiro exemplo acima não deveria ser capaz de enviar um método DELETE. Essa chamada de API seria vista como legítima e passaria por esses controles de segurança.
WAFs e gateways de API às vezes suportam filtros de mensagens explícitos e estaticamente definidos, frequentemente referidos como uma abordagem de segurança positiva. No entanto, essas abordagens podem inibir ou quebrar a funcionalidade de negócios, e a maioria das organizações as considera difíceis de operacionalizar em escala. Restringir métodos HTTP também é uma tarefa mais fácil do que restringir parâmetros e valores de API, sendo que este último requer um conhecimento mais aprofundado sobre o design da API.
A atividade no exemplo do New Relic acima seria ignorada por WAFs e gateways de API pela mesma razão. Esses controles de segurança não saberiam que os aplicativos de terceiros não deveriam mais ter acesso às funções de API obsoletas ou restritas. O ajuste dos controles teria exigido uma transferência de conhecimento apropriada entre as equipes de desenvolvimento, operações e segurança para implementar um filtro estático adequado no proxy apropriado dentro da arquitetura corporativa geral.
Como Proteger suas APIs Contra Vulnerabilidades de Autorização em Nível de Função Quebrada
As soluções de segurança de API devem ser capazes de estabelecer continuamente uma linha de base para padrões típicos de acesso HTTP por endpoint de API e por usuário. Com essa linha de base, as soluções de segurança de API podem identificar chamadas com parâmetros inesperados ou métodos HTTP enviados a endpoints de API específicos, como no primeiro exemplo acima.
É fundamental que uma ferramenta de segurança de API seja capaz de estabelecer uma linha de base continuamente, pois as APIs podem passar por uma alta taxa de mudança como resultado das práticas modernas de desenvolvimento e lançamento. As soluções de segurança de API devem ser capazes de identificar e impedir que invasores ou usuários não autorizados acessem recursos de nível administrativo ou funcionalidades não autorizadas.
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.