Guia OWASP para APIs 2023

Como desenvolvedores e/ou responsáveis pela segurança de uma empresa, aplicativo, informação e um longo etc., devemos ser capazes de definir o limite do certo e do errado ao construir e projetar suas arquiteturas. Muitas vezes acontece que no processo esquecemos de levar em conta os erros mais comuns cometidos por outros desenvolvedores ou, quando é diferente disso, esquecemos também os principais interesses dos atacantes. Se tivéssemos que nos manter atualizados por conta própria, seria uma tarefa titânica, pois as vulnerabilidades e os interesses dos atacantes por novos horizontes têm uma taxa de variação exponencial.

Isso levanta uma série de questões quando se trata de propor um design seguro para um aplicativo da Web, serviço da Web e/ou aplicativo móvel; Como nos mantemos atualizados, como lidamos com essa onda de notícias sem nos esquecermos do que é mais importante? Poderíamos facilmente dizer que o mais conveniente seria fazer uma lista das vulnerabilidades mais conhecidas com base na experiência pessoal, mas aí estaríamos levando em conta apenas uma única visão da situação, embora seja desejável que as empresas tenham um histórico de vulnerabilidades ou falhas anteriores para poder aplicá-las à melhoria contínua, também é verdade que esse histórico será baseado em um único tipo de arquitetura e/ou um único tipo de aplicativo. No curto prazo, isso pode não ter impacto no nível da empresa, mas se a empresa estiver constantemente imersa em processos de inovação, como deveria estar, ela sempre se encontrará no dilema de mudar constantemente a arquitetura e propor melhorias aos processos usuais desenvolvidos diariamente, levando-a a implementar novas funcionalidades e novas tecnologias que poderiam estar em risco sob a perspectiva desse histórico (baseado em uma arquitetura obsoleta).

É nesse ponto que temos de embaralhar e dar as cartas novamente, colocando-as em uma ordem alternativa que proporcione novos pontos de vista. Por que investir esforços na elaboração de estatísticas e na compilação de registros históricos se pode haver alguém que tenha feito a mesma coisa antes, mas não apenas com referência a uma arquitetura específica, mas também a muitas situações que ocorreram em diferentes campos?

Esse é o caso do OWASP, (Open Worldwide Application Security Project). Um projeto que surgiu da necessidade de destacar os interesses mais comuns dos invasores com base nos erros que os desenvolvedores cometem ao longo do ciclo de desenvolvimento de software, a comunidade OWASP é formada por empresas, organizações educacionais e indivíduos de todo o mundo. Juntos, eles formam uma comunidade de segurança de computadores que trabalha para criar artigos, metodologias, documentação, ferramentas e tecnologias que são lançadas e podem ser usadas gratuitamente por qualquer pessoa. Atualizando as principais tendências, como consequência dos aprimoramentos existentes nos processos de desenvolvimento seguro. Essa organização, que nasceu focada em erros associados a aplicativos da Web, tem hoje várias versões, tipificando as vulnerabilidades mais exploradas e agrupando-as de acordo com a natureza do aplicativo. Atualmente, temos o OWASP Web, o OWASP Mobile, e o OWASP API, que serão detalhados neste artigo:

OWASP - API 2023

Um elemento fundamental da inovação no mundo atual orientado por aplicativos é a interface de programação de aplicativos (API). De bancos, varejo, transporte a IoT, veículos autônomos e cidades inteligentes, as APIs são uma parte fundamental dos aplicativos móveis, SaaS e da Web modernos e, como são comumente encontradas no nível do cliente, estão se tornando um alvo principal para os invasores quando são descuidados em sua implementação.

Embora o conceito de uma API seja simples, um serviço que fornece um recurso e uma interface do outro lado que consome os vários recursos, conforme mostrado na imagem; a maioria dos desenvolvedores pula o processo de protegê-los, talvez por uma falsa sensação de segurança que os leva a pensar que um invasor, sem saber como funciona, não terá como alvo esses serviços porque eles estão fora da superfície de ataque. Na realidade, o oposto é verdadeiro.

Veja a seguir as 10 vulnerabilidades mais frequentes nessa área:

API1 - Broken Object Level Authorization

A autorização no nível do objeto é um mecanismo de controle de acesso, geralmente implementado no nível do código, responsável por validar que um usuário acesse somente os objetos que ele tem permissão para acessar. Supondo que um usuário apresente suas credenciais à interface hospedada no telefone e depois queira acessar outro recurso fornecido pelo serviço, como segue:

Se for retorndo ao sistema qualquer objeto não relacionado às suas credenciais e essa proteção falhar, estaremos na presença de uma autorização de nível de objeto quebrada, de modo que um invasor poderá acessar facilmente qualquer objeto.

API2 - Broken Authentication

Essa falha, comum também em aplicativos da Web, pode se manifestar em várias vulnerabilidades porque, quando nos deparamos com um endpoint de API, há um desafio inicial para consumir a API e começar a trocar recursos.

Há vários casos em que isso pode ocorrer:

• Se a API estiver vulnerável a ataques de Credential Stuffing, em que os invasores usam credenciais conhecidas de contas e/ou nomes de usuário vazados em um vazamento recente.
• Se a API permitir senhas fracas ou mecanismos de autenticação fracos, como: Autenticação básica
• Se a API trocar dados por meio de parâmetros GET, isso permitirá o vazamento de dados de autenticação por meio da memória ociosa hospedada no dispositivo da vítima.
• Se os tokens JWT forem usados, mas não validados durante a transação.
• Se os tokens usados não tiverem a data de validade correta configurada
• Se o endpoint não tiver proteção contra ataques de força bruta (implementação ruim ou inexistente de captcha).
• Se algoritmos fracos forem usados para criptografia de dados, em repouso e em trânsito.

Cenário em potencial:

• Um invasor invoca o módulo reset-password, o que resulta na invocação de um módulo semelhante a este /api/v1/reset-password.



• Em seguida, a API envia automaticamente um comando de redefinição para o usuário 456 e, como consequência, o serviço envia um token de redefinição de 5 dígitos para a caixa de correio do usuário afetado. Na interface, você será solicitado a inserir o token.


• Ao inserir qualquer token, o invasor captura a solicitação e pode ler uma solicitação semelhante a esta;



• Como o serviço da Web não tem a proteção adequada, o invasor pode executar uma força bruta com a ferramenta Burp para adivinhar o token de 5 dígitos, estando na presença de um ataque de autenticação de usuário quebrada.

API3 - Broken Object Property Level Authorization

Essa categoria de vulnerabilidades combina duas vulnerabilidades descritas na revisão de 2019 associadas a APIs, em que temos exposição excessiva de dados e atribuição em massa, basicamente focadas na manipulação de informações confidenciais e na exposição desse tipo de informação, referentes às propriedades dos objetos.

Um exemplo simples dessa vulnerabilidade poderia ser o seguinte;

• El usuario ingresa el número de tarjeta y los datos correspondientes para realizar una compra.
• Luego estos datos son transferidos desde el API gateway a la “API Interna”. (Hasta aquí ningún inconveniente)
• Al recibir estos datos, la API envía una respuesta con muchos más datos de los que debería enviar al usuario.

API4 - Unrestricted Resource Consumption

Algumas consultas exigem recursos como largura de banda, consumo de CPU, memória e armazenamento, e outras têm esse poder de processamento delegado aos provedores de serviços, pois é muito provável que nem todas as APIs de um aplicativo estejam sob o controle da empresa que desenvolve o aplicativo. Muitas estruturas usam APIs de terceiros e pagam por solicitação, portanto, esses ataques estão associados a custos de manutenção prejudiciais para essas APIs.

Por exemplo:

• Um módulo de autenticação tem um formulário de recuperação de senha.
• Esse formulário de recuperação de senha tem um serviço externo de envio de SMS que incorre em um custo para cada solicitação gerada.
• Um invasor encontra uma maneira de consumir esse serviço gratuitamente, usando esse envio de SMS para outros fins sem a necessidade de apresentar credenciais.

API5 - Broken Function Level Authorization

Em primeiro lugar, os atacantes procuram um alvo que contenha dois ou mais tipos de conta. Pode ser um usuário comum, encarregado das tarefas habituais de seu perfil e, em outro caso, pode ser um usuário administrador, encarregado de ter uma visão geral de todo o problema. Ao capturar várias chamadas para a respectiva API, o invasor encontra um parâmetro oculto que se refere ao tipo de conta e, assim, passa a alterá-lo, permitindo o acesso a uma função de outro usuário que não corresponde às suas tarefas.

Em resumo, no tratamento da autorização, essas APIs vulneráveis não controlam adequadamente o acesso a funções que correspondem a perfis mais avançados.

Nessa imagem, o invasor simplesmente substitui o módulo usuários por administrador e acessar todas as informações dos usuários.

API6 - Unrestricted Access to sensitive business flows

Ao criar um endpoint, é muito importante entender quais são os fluxos de negócios mais importantes, geralmente aqueles que carregam as informações mais críticas da empresa e de suas operações, de modo que protegê-los se torna a principal tarefa de todo programador. Se esses fluxos forem expostos, poderemos ter um impacto de médio a crítico na operação do aplicativo, dependendo do fluxo de negócios que foi exposto por meio dessas falhas.

Alguns exemplos comuns de fluxos de negócios expostos são apresentados nas seguintes situações:

• Um invasor que tem a capacidade de comprar todos os produtos que estão em alta demanda devido aos pontos fracos dos aplicativos e depois vendê-los por um preço mais alto.
• Criar SPAM em um sistema que tenha exposto o fluxo de criação de comentários e/ou postagens.
• Um fluxo de reservas de assentos em um cinema que, quando exposto, dá ao invasor a possibilidade de reservar todos os assentos.

Como vimos nesses três casos, as APIs apresentam essas vulnerabilidades porque a autenticação não é necessária para usar esses recursos. Isso permite que um usuário ignore o fluxo normal do aplicativo e vá para fluxos alternativos que não correspondem ao fluxo natural do aplicativo.

Imagem extraída do site https://medium.com/

API7 - Server Side Request Forgery

Essa vulnerabilidade ocorre quando uma API permite consultas HTTP do lado do servidor a um domínio arbitrário da escolha do invasor.

Isso permite que um invasor se conecte aos serviços de infraestrutura interna onde a API está hospedada e vaze informações confidenciais.

Os casos são variados, mas vamos dar uma olhada em como um invasor pode roubar as chaves do AWS de uma empresa.

• ⦁ Suponha que uma solicitação da Web que consulta o estoque de um produto tenha a aparência mostrada nas imagens abaixo.
• ⦁ Nesse caso, um invasor poderia modificar a consulta para, em vez de solicitar dados de estoque do produto, solicitar metadados da API e encontrar uma lista de funções válidas.
• ⦁ Embora a API tenha inicialmente uma restrição de acesso que impede a realização de consultas externas, a consulta é originária do servidor. Portanto, a API responderá à consulta como se estivesse autorizada a fazê-lo.

API8 - Security Misconfiguration

Assim como nos aplicativos da Web, há configurações de segurança ruins nas APIs. Isso ocorre quando o hardening correto da plataforma não é aplicado ou quando as permissões são configuradas incorretamente ao implantá-las. Entre os problemas a serem revisados, os desenvolvedores tendem a omitir a maioria daqueles que são relacionados à segurança devido à falta de automação no estágio de teste. Entre as possíveis configurações incorretas estão as seguintes:

• Patches atualizados mais recentes
• Serviços desnecessários ativados
• Falta de controles e/ou diretivas de cache
• Falta de política sobre o uso de CORS
• Manuseio incorreto de erros

API9 - Improper Inventory Management

As APIs tendem a expor mais pontos de extremidade do que os aplicativos da Web tradicionais, o que leva os desenvolvedores a criar a documentação correspondente da operação de cada uma das APIs correspondentes. O inventário adequado deve ser preservado porque, se a documentação for perdida ou vazada, os invasores poderão expandir sua superfície de ataque, maximizando seu conhecimento sobre como lidar com os serviços expostos.

Essa vulnerabilidade, juntamente com a falta de proteção, torna-se a principal bomba-relógio associada a esses problemas. Devemos sempre nos perguntar, para cada API, se todos os endpoints atuais devem estar disponíveis, a fim de aplicar o princípio do menor privilégio a toda a configuração da arquitetura.

Nesta imagem, vemos a possível complexidade de documentar a operação de uma arquitetura que adiciona diferentes APIs à medida que elas são necessárias.

Em um caso de exemplo, vamos supor que, além disso, temos o seguinte URL:

⦁ < http://WEBSITE:5555/api/v2/res//all >

Se prestarmos atenção especial à construção da url, perceberemos que estamos trabalhando com a versão 2 da mesma. Um invasor que entenda esse tipo de operação poderia substituir a v2 por uma v1, para ver quais módulos estavam disponíveis relacionados à versão anterior da API. Muitas vezes, os desenvolvedores restringem módulos que não usam na nova versão, mas negligenciam versões anteriores que poderiam estar ativas como resultado de uma pesquisa incorreta ao criar o inventário.

API10- Unsafe Consumption of APIs

Os desenvolvedores tendem a receber dados de APIs de terceiros e, muitas vezes, esses consumos que estão sob a órbita da arquitetura corporativa não têm um tratamento de segurança adequado ao restante dos fluxos do aplicativo que consome esses serviços.

Assim, a negligência desses componentes cria uma superfície de ataque interessante do ponto de vista do criminoso cibernético, pois ele pode usar esses recursos para prejudicar a operação do aplicativo.

Como pode ser visto na imagem, se eu tiver meus endpoints de API e eles forem controlados, por exemplo, por um API Management de terceiros, um invasor que encontrar uma falha nesse componente de terceiros poderá violar toda a arquitetura projetada anteriormente. É por isso que os desenvolvedores precisam estar constantemente cientes das falhas que podem existir nos sistemas que são contratados e terceirizados.

Recomendações

Ao pensar em como nos proteger desses problemas, eu diria que o que precisamos fazer é aumentar nossa conscientização sobre os ativos de TI que implantamos quando criamos um aplicativo. É importante seguir as recomendações da OWASP em cada ponto para poder executar uma implementação correta das APIs e não abusar da possível ignorância dos invasores. Convidamos você a visitar o OWASP API security Project para obter soluções mais específicas para cada caso. Se você gostou deste post e quer que façamos um relacionado às recomendações, deixe sua opinião nos comentários.

Conclusão

O principal erro é, em primeiro lugar, acreditar que ninguém prestará atenção a um determinado ponto de nossa arquitetura e, além disso, acreditar que a segurança por obscuridade (uso de design secreto como medida de proteção, segurança por ignorância) é o mecanismo mais eficaz para nos defendermos quando, na realidade, em muitas ocasiões os invasores sabem mais do que nós sobre nosso próprio aplicativo.