Skip links

Quer testar e mitigar os principais riscos e ameaças em APIs? Elaboramos um guia passo a passo para ajudar você

As APIs (Interfaces de Programação de Aplicativos) desempenham um papel fundamental na comunicação e interação entre diferentes plataformas e aplicativos. E podem ser pontos de entrada para invasores que procuram acesso a dados confidenciais, funcionalidades críticas e sistemas subjacentes. A estratégia é adotar uma abordagem proativa para identificar e mitigar possíveis vulnerabilidades nessas interfaces.

Neste artigo, exploraremos uma lista dessas principais vulnerabilidades de segurança, em detalhes. A ideia é fornecer um guia passo a passo sobre como testar e mitigar efetivamente esses riscos. Para realizar os testes, utilizaremos o crAPI, plataforma de teste de vulnerabilidades em APIs. Oferece desafios de segurança realistas para aprendizado e prática.

Ao examinar cada uma dessas vulnerabilidades, compreenderemos as causas, potenciais impactos e estratégias recomendadas para testá-las e mitigá-las efetivamente.

Centralize informações, gerencie o risco, acelere a tomada de decisão. Conheça o RIS, a plataforma SaaS desenvolvida pela Redbelt Security que concentra e correlaciona informações e logs de segurança, gerando indicadores em um dashboard amigável e intuitivo. Saiba mais

BOLA Vulnerabilities (Broken Object-Level Authorization)

As vulnerabilidades BOLA (Broken Object-Level Authorization) são uma preocupação significativa em aplicações baseadas em API. Essas falhas permitem que os atacantes manipulem IDs de objetos nas solicitações de API para acessar dados sensíveis de forma não autorizada. Esse tipo de vulnerabilidade é comum porque muitas vezes os servidores não monitoram adequadamente o estado do cliente, confiando demasiadamente em parâmetros como IDs de objetos para decidir o acesso.

Mesmo que as aplicações implementem verificações de autorização, os desenvolvedores podem falhar em aplicar essas verificações corretamente, aumentando o risco de acesso não autorizado a informações sensíveis. A detecção dessas falhas geralmente não é fácil de ser realizada por meio de testes automatizados, tornando crucial uma abordagem cuidadosa na implementação de controles de acesso em APIs.

Para ilustrar essa vulnerabilidade, com o proxy Burp Suite, realizamos a chamada da API que nos permite identificar as coordenadas geográficas do nosso veículo.

Figura 1 – Localização do veículo

Há outra chamada dedicada aos comentários dos usuários. Podemos observar que as informações dos usuários são expostas, incluindo o ID do veículo.

Figura 2 – Comentários dos usuários

Ao inserirmos o ID do veículo do usuário Robot na chamada de localização, poderemos acessar suas coordenadas geográficas.

Figura 3 – Identificando a localização

O impacto dessa vulnerabilidade pode ser significativo, permitindo que usuários não autorizados acessem informações sensíveis isso pode resultar em riscos à segurança e privacidade dos usuários, além de possíveis consequências adversas, como o rastreamento não autorizado de veículos e a exposição de informações confidenciais.

Para mitigar esse tipo de falha, é essencial implementar um controle de acesso adequado nas funcionalidades da aplicação. Isso pode ser feito através da autenticação dos usuários e da autorização, garantindo que apenas usuários autorizados tenham acesso às informações sensíveis, como as coordenadas geográficas dos veículos.

Broken User Authentication

As vulnerabilidades BUA (Broken User Authentication) são uma grande preocupação em aplicações que utilizam APIs. Estas falhas ocorrem quando os mecanismos de autenticação são mal implementados, permitindo que atacantes comprometam tokens de autenticação ou explorem falhas de implementação para assumir identidades de usuários legítimos. Detectar e corrigir essas vulnerabilidades exige uma abordagem cuidadosa e rigorosa na implementação de práticas de autenticação segura.

Nesta chamada, são enviados o email, o OTP (One-Time Password) e a senha para realizar o login na aplicação, porém não temos conhecimento do código correto do OTP.

Figura 4 – Requisição de login

Quando tentamos adivinhar o valor correto utilizando o método de força bruta, recebemos uma mensagem indicando que estamos fazendo muitas tentativas.

Figura 5 – Bruteforce no OTP [1]

No entanto, se utilizarmos a versão 2 em vez da versão 3 da API, é possível fazer várias requisições e obter o código de OTP correto.

Figura 6 – Alteração da versão da API
Figura 7 – Bruteforce no OTP [2]

A vulnerabilidade relacionada ao OTP (One-Time Password) pode ter um impacto significativo na segurança da aplicação. Permitir múltiplas tentativas de login com diferentes códigos de OTP pode facilitar ataques de força bruta, comprometendo a integridade das contas dos usuários e expondo informações sensíveis.

A troca do caminho da API de v3 para v2 permitiu que o atacante contornasse as restrições de tentativas de login e realizasse com sucesso o brute force para obter o código de OTP correto. Uma abordagem eficaz para mitigar esse tipo de falha seria implementar medidas adicionais de segurança na API, independentemente da versão. Isso poderia incluir limites de taxa para as solicitações de OTP, bloqueio temporário de contas após um número excessivo de tentativas de login falhadas, ou até mesmo a introdução de métodos de autenticação mais robustos, como autenticação de dois fatores (2FA).

Excessive Data Exposure

A exposição excessiva de dados é uma preocupação significativa em sistemas de informação, especialmente em aplicações que fazem uso de APIs. Essa vulnerabilidade ocorre quando os sistemas expõem mais dados do que o necessário, o que pode resultar na divulgação não autorizada de informações sensíveis dos usuários. Detectar e corrigir essas vulnerabilidades requer uma análise minuciosa das políticas de privacidade e segurança dos dados, bem como a implementação de medidas para restringir o acesso apenas às informações necessárias para cada usuário.

Nessa chamada, podemos visualizar as publicações recentes dos usuários. No entanto, observamos que a API nos fornece mais informações do que o necessário, como ID, ID do veículo e e-mail.

Figura 8 – Publicações recentes

A exposição excessiva de dados pode levar à violação da privacidade dos usuários e ao acesso não autorizado a informações sensíveis. Além disso, os dados expostos podem ser explorados por atacantes para realizar atividades maliciosas, como phishing, engenharia social e fraudes. A exposição de informações confidenciais pode prejudicar a reputação da empresa, causar danos financeiros e resultar em ações legais por violação de privacidade. Essa vulnerabilidade também pode comprometer a confiança dos usuários na plataforma, levando à perda de clientes e negócios.

Para mitigar a exposição excessiva de dados na API, é fundamental revisar e restringir os dados retornados nas respostas das chamadas de API, fornecendo apenas as informações necessárias para o funcionamento da aplicação. Além disso, é importante implementar mecanismos de controle de acesso e autenticação adequados para garantir que apenas usuários autorizados possam acessar os dados sensíveis. Isso pode incluir a utilização de tokens de autenticação com escopos limitados e a aplicação de políticas de segurança de dados, como criptografia e mascaramento de informações confidenciais.

Rate Limiting

O rate limiting, ou limitação de taxa, é uma medida crucial de segurança em aplicações que utilizam APIs. Essa prática ajuda a prevenir ataques de negação de serviço (DoS) e de força bruta, limitando o número de requisições que um usuário pode fazer em um determinado período. Implementar o rate limiting de forma eficaz requer uma abordagem cuidadosa e rigorosa na configuração dos parâmetros de limitação, como o número máximo de requisições permitidas por segundo, minuto ou hora, e na identificação e diferenciação de usuários legítimos de possíveis atacantes.

Nessa chamada, a função é contatar o mecânico. Note que há dois parâmetros importantes nessa requisição: “repeat_request_if_failed”, definido como “false”, e “number_of_repeats”, definido como “1”. Esses parâmetros são responsáveis por efetuar uma nova tentativa de contato em caso de falha da primeira solicitação.

Figura 9 – Contatar mecânico

Ao alterarmos o primeiro parâmetro mencionado para true e definir o número de tentativas para dez mil, conseguiremos causar uma indisponibilidade no sistema, como podemos ver na imagem abaixo, onde o servidor nos retornou o erro 503 o que nos indica que o servidor está temporariamente indisponível para processar a solicitação devido à sobrecarga.

Figura 10 – Incremento de tentativas

A ausência de rate limiting pode resultar em uma sobrecarga do sistema devido ao grande volume de requisições, levando àindisponibilidade do serviço e possivelmente abrindo espaço para ataques de negação de serviço (DoS) e de força bruta, comprometendo a disponibilidade e a segurança da aplicação.

Para mitigar esse problema, é essencial implementar uma estratégia de rate limiting eficaz, configurando limites adequados para o número de requisições por usuário em um determinado período. Além disso, é importante monitorar constantemente o tráfego e ajustar os limites conforme necessário para proteger a aplicação contra sobrecargas e ataques. Remover os parâmetros responsáveis por definir a quantidade de tentativas de repetição em caso de falha da solicitação também é uma medida recomendada para evitar possíveis abusos e garantir a estabilidade do sistema.

Broken Function Level Authorization (BFLA)

Broken Function Level Authorization (BFLA) é uma vulnerabilidade de segurança que ocorre quando as funções de autorização não são aplicadas corretamente em uma aplicação web ou API. Isso permite que usuários não autorizados acessem funcionalidades ou recursos que deveriam estar restritos apenas a usuários autenticados ou com permissões específicas. Essa falha pode ocorrer quando a aplicação confia exclusivamente na interface do cliente para fazer cumprir as políticas de autorização, em vez de validar as permissões do usuário em cada solicitação.

Nessa chamada da API, o método PUT é utilizado para renomear o nome de um vídeo.

Figura 11 – Renomeação de vídeo

Com a intenção de verificar quais outros métodos são aceitos pela aplicação, alteramos de PUT para OPTIONS e obtivemos 5 métodos aceitos.

Figura 12 – Identificação dos métodos

Utilizamos o método DELETE e obtivemos a resposta informando que essa é uma função administrativa.

Figura 13 – Alteração de método

Alteramos o caminho de “user” para “admin” e conseguimos excluir o vídeo com sucesso.

Figura 14 – Alteração de usuário

Por fim, conseguimos excluir os vídeos 15, 18, 21, 24 e 27, que pertencem a outros usuários.

Figura 15 – Bruteforce no ID do vídeo

Essa vulnerabilidade permite que um usuário não autenticado ou com permissões limitadas acesse e modifique recursos que deveriam ser restritos. Isso pode levar à exclusão indevida de vídeos pertencentes a outros usuários e à execução de funções administrativas não autorizadas. O impacto dessa vulnerabilidade é grave, comprometendo a integridade e a segurança dos dados da aplicação, podendo resultar em perda de informações e violação da privacidade dos usuários.

Para mitigar essa vulnerabilidade, é essencial implementar um controle de acesso adequado na aplicação. Isso inclui a validação das permissões de cada usuário em cada solicitação, garantindo que apenas usuários autenticados e autorizados possam acessar e modificar recursos específicos. Além disso, é recomendável utilizar práticas de desenvolvimento seguro, como princípio do menor privilégio, para reduzir a exposição de funcionalidades administrativas e restringir o acesso a recursos sensíveis apenas a usuários autorizados.

Mass Assignment

A atribuição em massa é uma vulnerabilidade de segurança que ocorre quando um atacante pode manipular os dados de entrada para modificar as propriedades de um objeto, frequentemente resultando em alterações não autorizadas em um sistema. Isso pode ocorrer quando os desenvolvedores não validam e sanitizam adequadamente as entradas do usuário ou não restringem quais propriedades podem ser modificadas em um objeto. Para mitigar esse tipo de vulnerabilidade, é essencial implementar validação robusta e sanitização dos dados de entrada, além de restringir quais propriedades podem ser modificadas.

Nessa chamada, a função é adicionar produtos ao carrinho de compras. Podemos observar que os parâmetros product_id e quantity estão presentes, e podemos verificar na resposta o valor que nos resta após a compra.

Figura 16 – Adição de produtos ao carrinho

Ao alterarmos o parâmetro responsável pela quantidade para um valor negativo, conseguimos realizar um novo pedido e obter um saldo maior do que anteriormente.

Figura 17 – Inserção de valor negativo

A vulnerabilidade descrita permite aos atacantes adquirirem produtos com saldo negativo, resultando em perdas financeiras para a empresa. Essa brecha compromete a integridade das transações e pode afetar a confiança dos clientes na plataforma de compras. Além disso, abre espaço para fraudes e manipulação dos registros de vendas, comprometendo a precisão dos dados financeiros. Para a empresa, isso pode resultar em prejuízos financeiros e danos à reputação

Para mitigar essa vulnerabilidade, é essencial implementar validações robustas nos parâmetros enviados nas requisições de adição de produtos ao carrinho de compras. Isso inclui verificar a validade dos valores fornecidos para evitar a manipulação de quantidades e preços. Além disso, é recomendável implementar controle de acesso adequado para garantir que apenas usuários autenticados e autorizados possam realizar operações de compra.

SSRF (Server-Side Request Forgery)

SSRF, ou falsificação de solicitação do lado do servidor, é uma vulnerabilidade de segurança que ocorre quando um atacante pode induzir o servidor a fazer solicitações não autorizadas em seu nome. Isso pode resultar em acesso não autorizado a sistemas internos, vazamento de informações confidenciais ou até mesmo comprometimento total do servidor. Para mitigar o SSRF, é fundamental validar e filtrar cuidadosamente todas as entradas de URL fornecidas pelos usuários, além de implementar lista de permissões de hosts e regras de firewall para restringir destinos de solicitação. Além disso, é importante configurar o servidor para não realizar solicitações para recursos internos ou sensíveis.

Essa chamada da API é responsável por contatar o mecânico e, no corpo da requisição, há um parâmetro contendo um link dedicado ao relatório da solicitação.

Figura 18 – Chamada da API para contatar o mecânico

Alteramos esse endereço do nosso servidor e conseguimos concluir a requisição.

Figura 19 – Alteração do link

Nos logs do nosso servidor, podemos identificar que recebemos uma requisição da API, ou seja, conseguimos falsificar requisições por meio dela.

Figura 20 – Logs do servidor

O impacto dessa vulnerabilidade pode ser grave, uma vez que permite que um invasor manipule as solicitações feitas através da API. Isso significa que o invasor pode executar ações não autorizadas no sistema, como acessar informações confidenciais, modificar dados ou até mesmo realizar ações maliciosas que comprometam a integridade do sistema. Além disso, essa vulnerabilidade pode abrir caminho para ataques mais amplos, como explorações adicionais de outras vulnerabilidades ou até mesmo ataques de negação de serviço.

Para mitigar a vulnerabilidade de SSRF (Server-Side Request Forgery), é essencial implementar várias medidas de segurança. Algumas delas incluem:

  • Validar e filtrar cuidadosamente todas as entradas de URL fornecidas pelos usuários para garantir que apenas URLs válidas e seguras sejam aceitas;
  • Implementar lista de permissões de hosts e regras de firewall para restringir os destinos de solicitação, permitindo apenas comunicações com hosts confiáveis e autorizados;
  • Configurar o servidor para não realizar solicitações para recursos internos ou sensíveis, impedindo assim o acesso a sistemas internos não autorizados;
  • Monitorar de perto os logs do servidor em busca de atividades suspeitas ou tentativas de SSRF, respondendo rapidamente a quaisquer alertas ou indicadores de comprometimento;
  • Manter-se atualizado com as melhores práticas de segurança e patches de segurança para mitigar quaisquer novas vulnerabilidades de SSRF que possam surgir.

A segurança das APIs é uma preocupação crescente à medida que a integração de sistemas e serviços se torna cada vez mais comum na era digital. Este artigo explorou uma lista das principais vulnerabilidades de segurança em APIs, destacando a importância de adotar uma abordagem proativa para identificar e mitigar esses riscos.

Ao detalhar cada uma dessas vulnerabilidades – desde Broken Function Level Authorization (BFLA) até Server-Side Request Forgery (SSRF) – e fornecer exemplos práticos de como elas podem ser exploradas, esperamos ter fornecido insights valiosos sobre os desafios de segurança enfrentados pelas APIs.

É crucial que as organizações invistam em testes de segurança robustos para suas APIs, além disso, implementar práticas recomendadas de segurança, como autenticação adequada, controle de acesso granular e validação de entrada de dados, é fundamental para proteger os ativos digitais contra ameaças cada vez mais sofisticadas.

Em última análise, ao adotar uma abordagem proativa para a segurança das APIs e permanecer vigilante em relação às novas ameaças e vulnerabilidades emergentes, as organizações podem garantir a integridade, confidencialidade e disponibilidade de seus dados e sistemas, mantendo a confiança dos clientes e parceiros comerciais.

Guilherme Neves – consultor pentester da Redbelt Security

This website uses cookies to improve your web experience.
Explore
Drag