Recentemente a organização OWASP liberou a Release Candidate (RC) das dez vulnerabilidades mais comuns em APIs (Application Programming Interface). De modo geral, a RC serve para que desenvolvedores, pesquisadores e entusiastas possam contribuir com o ranking por meio de comentários e sugestões de modo que exista um ajuste fino das vulnerabilidades, visando o lançamento da versão final do guia, previsto ainda para 2023.

Neste artigo, discutiremos a RC falando sobre as vulnerabilidades elencadas nessa versão inicial do guia, comentando o funcionamento de cada item e, também, descrevendo algumas das principais formas de prevenção.

API 1: 2023 – Broken Object Level Authorization

A vulnerabilidade de Broken Object Level Authorization trata de uma falha que permite que um determinado usuário consiga acesso indevido a objetos que não lhe pertencem. Com esta falha, um usuário mal intencionado pode obter acesso à dados de outros usuários como, também, acesso às informações da aplicação consideradas confidenciais.

Para explorar esta vulnerabilidade o atacante pode simplesmente manipular determinado campo da requisição efetuada a alguma API, como por exemplo um campo de ID. Nesta situação, se a API alvo for de fato vulnerável, ela não fará nenhuma verificação de permissão de acesso ao objeto requisitado, ocasionando uma violação de segurança.

Prevenção

Como prevenção, o projeto OWASP elenca os seguintes tópicos para melhorar a segurança da API neste tipo de vulnerabilidade:

• Criar mecanismos de segurança que validem a permissão de acesso a objetos por meio de políticas de usuário e hierarquia;
• Usar valores randômicos e imprevisíveis para IDs como GUIDs;
• Criar suítes de testes para validar a segurança da API.

API 2: 2023 – Broken Authentication

Broken Authentication é uma vulnerabilidade relacionada a um mecanismo de autenticação da API que não verifica apropriadamente um usuário antes de conceder acesso a setores restritos.

Por meio dessa vulnerabilidade, um atacante pode se autenticar em nome de outro usuário, nomear usuários e senhas por meio de ataque de força bruta e efetuar ações maliciosas em nome de outros usuários.

Uma API está vulnerável em Broken Authentication quando apresenta mecanismos de autenticação fracos ou, quando apresenta uma implementação fraca do mecanismo, sem levar em consideração diversos vetores de ataques.

Prevenção

Para prevenir a vulnerabilidade, os seguintes tópicos são indicados:

• Garantir que todos os fluxos de autenticação estão especificados;
• Evitar “reinventar a roda” na área de autenticação mediante API, focar no que a literatura sugere;
• Implementar mecanismos para mitigar ataques de força bruta em todos os endpoints da API;
• Exigir uma nova autenticação para operações sensíveis.

API 3: 2023 – Broken Object Property Level Authorization

Broken Object Property Level Authorization refere-se a um problema em que a API vulnerável não consegue controlar com precisão o acesso a propriedades sensíveis de um objeto. Nesse sentido, um atacante que explorar essa falha pode modificar ou sequestrar dados por meio do corpo de uma requisição.

Para conseguir acesso a informações sensíveis, um usuário mal intencionado pode manipular requisições testando várias formatações distintas. Ferramentas de automação podem auxiliar nesse processo, auxiliando o atacante na busca por propriedades sensíveis em objetos.

Prevenção

As seguintes sugestões visam minimizar o problema de Broken Object Property Level Authorization:

• Garantir que o usuário responsável pela requisição tenha acesso ao objeto retornado;
• Assegurar com o usuário só possa realizar mudanças em dados que deveria ter acesso;
• Evitar métodos genéricos para manipulação dados como to_json() e to_string(), e definir em alta especificidade as propriedades retornadas;
• Implementar respostas a requisições baseadas em esquemas.

API 4: 2023 – Unrestricted Resource Consumption

Unrestricted Resource Consumption, como o próprio nome sugere, é um problema na definição de limites no que tange à utilização de recursos de uma API. Desta maneira, um usuário malicioso pode gerar dezenas de requisições concorrentemente exaurindo recursos destinados a API como memória, limite de banda, espaço em disco, uso de processos, etc.

Diversos problemas podem surgir em decorrência do esgotamento de recursos da API, como por exemplo, postergação indefinida de retorno de resposta e indisponibilidade do serviço.

Prevenção

Os seguintes tópicos são indicados para evitar a Unrestricted Resource Consumption:

• Implantar soluções que facilitem a definição de limite de recursos, como containeres;
• Definir limites de tamanho para dados de input para parâmetros e propriedades dos objetos;
• Implementar técnicas de rate limit para cada cliente;
• Definir validações no lado servidor que especifiquem um limite máximo de entradas na resposta.

API 5: 2023 – Broken Function Level Authorization

Em Broken Function Level Authorization, um usuário consegue ter acesso a funções da API que não deveria. Desta forma, um usuário mal intencionado pode usufruir de um endpoint exposto para performar ataques que alterem, modifiquem ou excluam dados.

Para investigar se uma API encontra-se vulnerável, usuários podem usar ferramentas automatizadas para procurar endpoints. Uma vez encontrado um endpoint com funções de nível administrativo, ataques são performados para manusear dados por meio deste endpoint.

Prevenção

As seguintes sugestões são indicadas para prevenir Broken Function Level Authorization:

• Revisar constante as permissões dos endpoints da API priorizando se endpoints de nível administrativo estão bloqueando acessos apropriadamente;
• Implementar um mecanismo que por padrão efetue bloqueios em todo tipo de acesso, especificando se cada tipo de cliente tem acesso a cada tipo de endpoint.

API 6: 2023 – Server Side Request Forgery

Server Side Request Forgery (SSRF) é um problema que ocorre quando uma API realiza uma requisição a um recurso externo por meio de uma URL definida pelo próprio atacante. Uma API demonstra-se vulnerável em SSRF quando algum dos endpoints exige uma URL como determinada propriedade do objeto envolvido na requisição, realizando em seguida alguma coleta desse recurso provido pela URL maliciosa.

 Além da injeção de uma URL maliciosa no corpo da requisição, é possível também que a URL possa ser adicionada diretamente nos cookies, cabeçalhos ou até em setores das bibliotecas utilizadas pela aplicação.

Prevenção

Os seguinte itens são indicados para prevenção da SSRF em APIs:

• Usar whitelists para definir:
  • Origens que a API pode interagir para adquirir determinado recurso (Google Drive, e.g.);
  • Tipos de mídia permitidas;
  • Schemas de URL e portas específicas;
• Isolar a funcionalidade de realizar requisições recursos do resto da aplicação;
• Desabilitar redirecionamento de requisições HTTP;
• Validar todo e qualquer arquivo adicionado pelo cliente.

API 7: 2023 – Security Misconfiguration

Uma API que apresenta falha de Security Misconfiguration normalmente está com suas configurações de segurança mal formadas ou incompletas. Desta forma, um ataque consegue coletar informações sigilosas ou até mesmo performar ações maliciosas devido a erros relacionados a erros de configuração.

Para explorar a falha, é possível que um usuário mal intencionado explore uma API em busca de padrões e nomenclaturas previsíveis, informações sensíveis em logs ou arquivos de configurações ou recursos de testes.

Prevenção

Vários tópicos são indicados para se evitar Security Misconfiguration em APIs, sendo algumas delas:

• Garantir um processo rápido e preciso de deploy;
• Tarefas contínuas de preview e checagem das configurações listadas nas aplicações;
• Implementar automações que verifiquem se as configurações atendem ao propósito e se estão devidamente protegidas;
• Implementar apropriadamente a configuração de Cross-Origin Resource Sharing (CORS);
• Garantir encriptação da comunicação cliente-servidor;
• Especificar detalhadamente quais funções utilizam HTTP, todo o resto deve utilizar HTTPS.

API 8: 2023 – Lack of Protection from Automated Threats

A falha de Lack of Protection from Automated Threats é encontrada em APIs que não apresentam proteção a serviços automatizados, como bots e scrappers, por exemplo. Esses serviços podem exagerar na quantidade de requisições efetuadas a uma API podendo causar indisponibilidade.

Uma API demonstra-se vulnerável quando em determinado endpoint ela permite que uma ferramenta automatizada possa exercer diversas requisições concorrentemente.

Prevenção

Para evitar a Lack of Protection from Automated Threats, uma api deve:

• Identificar quais regras de negócio e fluxos da API não podem ser usados excessivamente;
• Escolher apropriadamente mecanismos de defesa para mitigar os riscos de ferramentas automatizadas para uma determinada regra de negócio;
• Identificar e limitar o acesso a API que estão tendo como origem outras máquinas.

API 9: 2023 – Improper Inventory Management

Uma API demonstra-se vulnerável em Improper Inventory Management quando apresenta uma gestão ineficiente de suas versões datadas. Uma API datada e exposta pode conter recursos, como bibliotecas de terceiros, frameworks e outras ferramentas que, por estarem desatualizados, acabam sendo vetores de ataques onde o usuário mal intencionado consegue acesso a dados sensíveis.

Ainda, um dos principais riscos de se manter expostas as versões antigas de uma API é que comumente elas ainda mantêm acesso a pontos sensíveis utilizados também pelas novas versões, como banco de dados por exemplo.

Prevenção

A seguir, algumas dicas para se evitar a Improper Inventory Management:

• Apresentar uma documentação robusta de todos os ambientes de API (produção, pré-produção, homologação e desenvolvimento);
• Documentar todos os serviços que interagem com cada ambiente de API, mapeando corretamente todos os serviços que utilizam dados sensíveis;
• Utilizar sistemas de proteção para cada ambiente de API, não apenas o ambiente de produção;
• Sempre que for necessário realizar correções de uma API em termos de segurança, aplicar o patch para todos os ambientes e versões.

API 10: 2023 – Unsafe Consumption of APIs

O problema de Unsafe Consumption of APIs se refere a APIs que consomem outras APIs sem validar e sanitizar os dados que estão recebendo. Desta forma, uma API que consome outra API sem validar inputs corre o risco de que um invasor intercepte a comunicação entre elas e adultere os dados que serão enviados à API solicitante. 

Uma vez que a comunicação entre APIs é interceptada com sucesso, é possível que um invasor consiga obter acesso a informações sensíveis que lhe dêem poder de ter acesso a outros setores da API alvo.

Prevenção

Como prevenção a Unsafe Consumption of APIs, sugere-se: 

• Avaliar as políticas de segurança de serviços de terceiros utilizados pela API;
• Garantir que toda comunicação entre APIs ocorra em um canal de comunicação seguro com TLS;
• Sempre validar os dados recebidos por uma API integrada;
• Manter uma whitelist de apis permitidas, bloqueando todo o resto e evitando redirecionamentos.

Conclusão

A OWASP é um projeto aberto de segurança em aplicações WEB que tem por objetivo elencar as vulnerabilidades mais comuns e, também, difundir as principais formas de se evitar que elas sejam exploradas.

Indo além das vulnerabilidades específicas de aplicações WEB, o projeto busca expandir o mesmo guia para área segurança de APIs, uma vez que estes recursos são amplamente utilizados por aplicações através da Internet.

Neste artigo, abordamos as 10 vulnerabilidades mais presentes em APIs na Release Candidate do guia a OWASP, previsto para lançamento no corrente ano. Para cada item, descrevemos em tópicos sugestões que podem ajudar a evitar que cada vulnerabilidade seja explorada por usuários mal-intencionados. É importante ressaltar que algumas das vulnerabilidades exibidas nessa RC podem ser mitigadas utilizando o WAF da XLabs Security.

Para mais informações a respeito da RC das dez vulnerabilidades mais comuns em APIs, você pode acessar a página do projeto no Github clicando aqui. Neste link você também encontrará em cada item da RC um guia detalhado contendo sobre como evitar que tais vulnerabilidades estejam presentes em sua API.