Como se preparar para um pentest de API

Uma API (Interface de Programação de Aplicativos) desempenha um papel importante ao permitir que diferentes aplicativos e sistemas se comuniquem e troquem dados.

No desenvolvimento moderno de software, o paradigma de cliente-servidor mudou de aplicativos monolíticos para a arquitetura de front-end e back-end. Atualmente, a maioria dos aplicativos web e aplicativos mobile nada mais é do que um front-end visualmente atrativo para um back-end de API que executa ações como buscar ou gravar dados em um banco de dados, contendo a lógica do aplicativo e muito mais.

Como as empresas e instituições continuam a depender de APIs para seus aplicativos essenciais, garantir a segurança dessas interfaces torna-se fundamental, e o teste de intrusão (também conhecido como pentest) é uma atividade essencial para qualquer organização que projete e desenvolva APIs descobrir vulnerabilidades antes de elas serem exploradas.

Nossa equipe realiza centenas de pentest de aplicações por ano e, com frequência, recebemos clientes com muitas perguntas sobre testes de intrusão e pentest de API, especialmente sobre como se preparar para essas avaliações, quais informações fornecer aos pentesters, quais ferramentas serão usadas, qual é a abordagem de teste ideal, os problemas de segurança mais comuns encontrados nas APIs etc.

Para responder às perguntas mais frequentes, decidimos criar este guia educacional para ajudar as empresas encarregadas de contratar um teste de penetração de API a tomar as decisões corretas ao selecionar um provedor de pentest capaz de fornecer testes de segurança de API bem-sucedidos.

O que é um pentest de API?

O pentest, ou teste de intrusão, de API é uma forma de teste de segurança que se concentra na avaliação dos controles de segurança de uma API, simulando ataques de um usuário mal-intencionado ou de um aplicativo de terceiros, com o objetivo final de encontrar vulnerabilidades e fortalecer as defesas e postura de segurança da API.

Normalmente, o processo envolve o descobrimento e interação direta com os endpoints de uma API e seus respectivos parâmetros, mecanismos de autenticação, controles de acesso e outros recursos relacionados à segurança (como rate limit) para identificar pontos fracos que poderiam ser explorados para comprometer os dados ou serviços que ela fornece. Independentemente de sua API ser baseada em REST, web services SOAP, WebSockets, gRPC ou GraphQL, ela pode ser testada quanto a vulnerabilidades de segurança.

O principal objetivo de um teste de intrusão de API é descobrir problemas de segurança em APIs que possam ser explorados por invasores e corrigir esses problemas (ou atenuar os riscos associados) antes que eles sejam utilizados de forma abusiva. Esse processo ajuda as organizações a atingir vários objetivos, como:

1. Identificação de pontos fracos de segurança no projeto e na implementação da API
2. Avaliar a eficácia dos controles de segurança de API já existentes
3. Aderir à conformidade (compliance) com os padrões e regulamentos do setor (por exemplo, GDPR, HIPAA, SOC 2, ISO 27001, PCI DSS)
4. Fornecer recomendações para corrigir ou mitigar as vulnerabilidades identificadas
5. Integração da segurança ao ciclo de vida do desenvolvimento de software usando scanners adequados para testes de segurança automatizados de API

Preparação para um pentest de API

A preparação para um pentest de API é uma etapa crucial que garante que o teste de segurança seja completo, relevante e tenha uma boa cobertura da superfície de ataque da API. Veja a seguir algumas etapas básicas importantes necessárias para se preparar para a avaliação:

Tenha um NDA em vigor

Não é preciso dizer que ter um contrato de confidencialidade e um acordo de não divulgação (NDA) adequados é uma etapa preparatória essencial para qualquer teste de intrusão de API.

Como o processo de teste envolve o possível compartilhamento de informações confidenciais sobre seus sistemas, é essencial garantir que essas informações sejam legalmente protegidas.

Defina o escopo do pentest

Antes de iniciar qualquer teste de invasão, é essencial definir claramente o escopo da avaliação. Essa etapa é crucial e afeta a eficácia e os resultados do pentest.

O escopo normalmente inclui a identificação das APIs e dos endpoints específicos a serem testados, o entendimento da funcionalidade e dos fluxos de dados das APIs e o estabelecimento das metas e dos objetivos do teste de intrusão.

Enquanto isso, também é importante definir o que está explicitamente fora do escopo. Esses podem ser sistemas que são críticos demais para serem interrompidos, sistemas ou integrações pertencentes a terceiros ou tipos de testes que podem ser muito agressivos ou arriscados à integridade do sistema.

Forneça documentação, arquivos Postman e Swagger, requisições de exemplo

Fornecer à equipe de pentest uma documentação abrangente da API, juntamente com Postman collections, arquivos Swagger e requisições de exemplo, além de informações sobre métodos de autenticação, como chaves de API, pode ajudar significativamente no processo de teste de segurança da API e desempenhar um papel importante no sucesso do projeto.

Essas informações dão aos analistas de segurança uma melhor compreensão de como as APIs foram projetadas para funcionar, quais dados elas manipulam e como interagem com outros componentes do sistema. A documentação deve incluir detalhes sobre cada endpoint da API, os métodos que eles suportam, o tipo de dados que esperam manipular, as estruturas de dados que usam e quaisquer dependências ou restrições conhecidas.

Exemplos e amostras de requisições HTTP válidas e respostas esperadas também são importantes para que o pentester realize o teste de segurança da API.

Caso sua API tenha complexidade adicional quando se trata de interagir com ela, como uso de requisições criptografadas, dados que são encoded, empacotados ou codificados em um formato específico ou faz uso de requisições criptograficamente assinadas por HMAC, certifique-se de que o pentester esteja armado com todas essas informações e tenha os meios necessários para interagir com os endpoints.

Pentest grey-box ou assistido por código-fonte

Em um pentest grey-box, os pentesters têm algum conhecimento do sistema que estão testando. Isso pode envolver o fornecimento de chaves de API para teste, contas de usuário ou outras credenciais de acesso.

É importante ressaltar que, quando se trata de testes autenticados, geralmente em testes de intrusão, a equipe exige um mínimo de duas credenciais para cada perfil de acesso que a API ou o aplicativo possa ter. Portanto, esteja preparado para atender a esse tipo de solicitação.

O teste autenticado permite que um pentester simule um cenário de ataque mais realista e identifique vulnerabilidades que podem não ser detectadas em um teste black-box, em que os analistas não têm conhecimento prévio sobre o sistema ou mesmo credenciais para interagir com os endpoints da API que exigem autenticação – se o mecanismo de autenticação for sólido o suficiente, o pentester não conseguirá interagir com os endpoints da API que exigem autenticação, o que significa que esses endpoints não poderão ser testados em busca de vulnerabilidades, pois é impossível até mesmo alcançá-los.

Opcionalmente, sua empresa pode considerar uma avaliação completa de white-box para o pentest de API. Nessa abordagem, a equipe de testes de penetração recebe o código-fonte da API e pode entender como ela funciona. Os pentests assistidos por código-fonte reduzem muitas suposições e abrem mais caminhos para a exploração, expondo, em muitos casos, vulnerabilidades que dificilmente seriam encontradas em uma abordagem grey-box ou black-box.

Entenda quais são as ferramentas comumente usadas em pentests de API

Nos testes de penetração de API, um pentester normalmente utiliza um conjunto de ferramentas para realizar suas avaliações de forma eficaz. Veja a seguir um breve resumo de algumas dessas ferramentas:

Postman e do Swagger UI

Postman e Swagger UI são ferramentas gráficas populares que servem como cliente de API usadas por desenvolvedores e testadores de software para enviar solicitações a uma API e receber respostas.

Elas fornecem uma interface amigável para a construção de requisições a serem enviadas aos endpoints da API. Ambas as ferramentas oferecem suporte a vários métodos de requisições HTTP, incluindo GET, POST, PUT, DELETE e outros, e permitem que os usuários incluam cabeçalhos e dados do corpo da requisição de maneira simples.

Elas também incluem recursos para escrever e automatizar testes para APIs e gerenciar diferentes ambientes para testes. Além disso, essas ferramentas geralmente podem gerar e publicar documentação de API, facilitando o compartilhamento de APIs entre as equipes (por exemplo, Postman collections).

Um cliente GraphQL

Se a sua API for baseada em GraphQL, muito provavelmente a equipe usará um cliente que facilita a interação com aplicativos que “falam” GraphQL.

Por exemplo, o Altair GraphQL Client é uma ferramenta rica em recursos para trabalhar com APIs escritas nessa tecnologia. Ela fornece uma maneira direta e gráfica para que os desenvolvedores e testadores escrevam consultas e mutações e as enviem para um endpoint GraphQL.

Há muitas outras ferramentas semelhantes para atingir o mesmo objetivo de fazer interface com as APIs GraphQL, e elas podem ajudar no pentesting.

Burp Suite Professional

O Burp Suite é uma ferramenta abrangente de teste de segurança de aplicativos web. Ela é usada por pentesters de aplicativos para executar tarefas como mapeamento da aplicação, análise e manipulação de requisições, automatização de ataques personalizados e muito mais.

Em um típico teste de penetração de API manual, um cliente como Postman, Altair GraphQL ou SoapUI é “proxiado” para o Burp Suite, onde ocorre o processo de teste de segurança.

Kiterunner

Kiterunner é uma ferramenta de descoberta de conteúdo contextual criada por Shubham Shah e nossos amigos da Assetnote. A ferramenta é capaz de fazer força bruta nos endpoints da API de forma contextual (ou seja, usando os cabeçalhos corretos, métodos HTTP e assim por diante).

Ela funciona de maneira distinta das ferramentas comuns de descoberta de conteúdo e brute force de diretório, e o reconhecimento do contexto o torna adequado para testes de penetração de APIs e aplicativos escritos em frameworks web modernos.

Ferramentas automatizadas de teste de segurança

As ferramentas automatizadas de teste de segurança podem proporcionar benefícios significativos durante um pentest de API, ajudando a aumentar a velocidade e a cobertura e a encontrar os bugs mais óbvios logo de cara.

Os scanners automatizados e open-source, como o OWASP ZAP e o BBVA’s API Check, foram especialmente projetados para detectar uma variedade de vulnerabilidades comuns de API, como as listadas no OWASP API Security Top 10. Eles podem examinar rapidamente as APIs baseadas em REST em busca de vulnerabilidades de injection, tratamento inadequado de erros, configurações incorretas e muito mais. Há vários outros scanners de segurança comerciais que também oferecem uma cobertura sólida para testes automatizados de segurança de API.

A vantagem de usar essas ferramentas como parte de um pipeline de DevSecOps é sua capacidade de se integrar aos sistemas de integração contínua/entrega contínua (CI/CD), fornecendo uma maneira de monitorar continuamente as vulnerabilidades à medida que as alterações são feitas na API. Essa automação permite que as equipes de desenvolvimento identifiquem e resolvam possíveis problemas no início do ciclo de vida do desenvolvimento, o que a torna uma parte essencial de uma postura proativa de segurança de aplicativos.

No entanto, embora essas ferramentas possam aumentar significativamente o processo de teste de penetração de API, é fundamental lembrar que elas não substituem o teste de penetração manual. Os scanners automatizados podem deixar passar vulnerabilidades específicas do contexto ou falhas de lógica comercial que um testador humano poderia identificar. Portanto, uma abordagem equilibrada que combine a varredura automatizada com testes manuais geralmente é a maneira mais eficaz de garantir a segurança abrangente da API.

Uma lista de recursos e várias ferramentas para segurança de API pode ser encontrada no repositório Awesome API Security do GitHub.

Vulnerabilidades e riscos comuns de APIs

As APIs têm seu próprio conjunto específico de classes de vulnerabilidade. Problemas comuns de segurança de aplicativos web, como cross-site scripting e vulnerabilidades específicas de front-end, geralmente têm menos relevância ou não se aplicam ao realizar testes de penetração de API. Lembre-se de que eles ainda podem ser relevantes se a entrada de dados enviada para a API for consumida em outro lugar em um aplicativo web.

Em junho de 2023, o novo OWASP API Security Top 10 2023 foi finalmente publicado. Como o nome indica, trata-se de uma lista dos dez riscos de segurança mais comuns encontrados em APIs, contendo insights e inteligência coletados de várias empresas de testes de intrusão nos últimos anos.

A seguir, discutiremos brevemente, com base em nossa própria experiência de pentesting de API, alguns dos problemas de segurança de API mais predominantes que encontramos em nossos pentests. É importante salientar que a lista não é exaustiva e que outras classes de problemas de segurança afetam as APIs, incluindo falhas específicas na lógica do aplicativo.

Problemas de controle de acesso – IDORs e BOLAs

Broken Object Level Authorization (BOLA) e Insecure Direct Object References (IDOR) são vulnerabilidades intimamente relacionadas que podem ocorrer em APIs.

A BOLA ocorre quando um endpoint de API não consegue verificar adequadamente se o usuário que está fazendo uma solicitação tem as permissões necessárias para acessar ou modificar o objeto que está solicitando.

As vulnerabilidades IDOR são instâncias específicas de BOLA em que a API expõe uma referência (como um ID ou nome) a um objeto de implementação interna. Os invasores podem manipular essas referências expostas para acessar recursos não autorizados.

Um exemplo de IDOR pode ser encontrado abaixo, retirado da Portswigger Academy:

Considerando um aplicativo em que o cliente faz login e pode editar as informações de sua própria conta:

https://insecure-website.com/customer_account?customer_number=132355

O que acontece quando o customer_number é modificado para outro número, por exemplo, 123654? Se o aplicativo ou a API for vulnerável a um IDOR, um atacante pode alterar dados pertencentes a outro usuário simplesmente modificando esse parâmetro.

As vulnerabilidades BOLA e IDOR podem levar à exposição não autorizada de dados, à manipulação de dados ou a outros impactos, dependendo da natureza do objeto ao qual o adversário obtém acesso.

Mass assignment

Mass assignment é uma classe de vulnerabilidade que surge quando um endpoint vincula automaticamente os dados de entrada do cliente (como dados JSON em um corpo de uma requisição) aos atributos do modelo. Em essência, ele permite que os usuários passem parâmetros que podem ser atribuídos diretamente aos atributos do modelo.

Um atacante pode manipular parâmetros e modificar propriedades de objetos que não deveria acessar, levando a possíveis alterações não autorizadas nos dados. Por exemplo, eles podem modificar os privilégios de um usuário, alterar a propriedade de um registro e outras ações inesperadas.

Um exemplo clássico de atribuição em massa foi extraído da OWASP. Em um fluxo típico de registro de usuário em um aplicativo, é possível ver a seguinte solicitação:

POST /addUser
…
userid=bobbytables&password=hashedpass&[email protected]

Se o aplicativo for vulnerável à mass assignment, poderá ser possível modificar outros atributos e campos na instanciação da classe, potencialmente aumentando os privilégios e muito mais:

POST /addUser

…

userid=bobbytables&password=hashedpass&[email protected]&isAdmin=true

Ausência de rate limit

O rate limit é um controle de segurança que determina quantas solicitações um cliente ou usuário pode fazer à API em um período de tempo específico. A ausência ou a implementação incorreta da rate limit pode deixar as APIs vulneráveis a ataques de força bruta, scrapping automatizado ou até mesmo negação de serviço.

Um invasor pode inundar a API com solicitações, o que pode levar à interrupção do serviço, obter acesso não autorizado adivinhando credenciais e contornar os planos de uso, billing e faturamento da API em termos de solicitações por segundo.

A implementação do rate limit ajuda a evitar esse comportamento abusivo e outras formas de ataques automatizados, garantindo que a disponibilidade e o desempenho da API sejam mantidos e que ela permaneça acessível a usuários legítimos.

Os rate limits devem ser definidos com base em um bom entendimento dos padrões de uso típicos da API e devem ser aplicados por cliente ou usuário para garantir o uso justo.

Exposição de dados confidenciais

A exposição de dados confidenciais ocorre quando uma API revela involuntariamente informações confidenciais, como informações de identificação pessoal (PII), detalhes de cartão de crédito ou dados de autenticação do usuário, devido a controles de segurança insuficientes ou implementados de forma inadequada. Essa vulnerabilidade geralmente surge quando os dados não são adequadamente protegidos em trânsito (in transit) ou em repouso (at rest) ou se dados confidenciais desnecessários forem incluídos nas respostas da API.

Por exemplo, uma API pode transmitir dados por meio de uma conexão não criptografada, deixando-a vulnerável à interceptação, ou pode armazenar dados confidenciais em texto simples em vez de criptografá-los. Além disso, controles de acesso inadequados podem fazer com que dados confidenciais sejam retornados a usuários que não deveriam ter acesso a eles.

Ataques de injection

As vulnerabilidades de injection ocorrem quando uma API não sanitiza adequadamente os dados de entrada antes de incorporá-los a uma instrução ou comando. Os atacantes podem explorar isso injetando comandos ou códigos maliciosos que a API executa.

Os problemas de injection podem se manifestar de várias formas, incluindo SQL injection, command injection, script injection, dependendo de onde a entrada não higienizada é usada. SQL injection, por exemplo, envolve a inserção de instruções SQL mal-intencionadas em uma solicitação de API, que pode manipular ou revelar informações confidenciais do banco de dados.

Para atenuar as vulnerabilidades de injection, é essencial higienizar e validar os dados de entrada, usar consultas parametrizadas ou instruções preparadas e aplicar princípios de privilégio mínimo para limitar o impacto potencial de um ataque.

Observações finais

A crescente prevalência de APIs em softwares modernos torna a segurança de APIs fundamental para todas as organizações. Desde os endpoints individuais da API até a arquitetura geral, todos os aspectos de uma API podem apresentar possíveis vulnerabilidades que os invasores podem tentar explorar.

O pentesting de APIs torna-se indispensável para garantir a robustez dos controles de segurança do seu aplicativo. É fundamental não apenas expor e solucionar as vulnerabilidades atuais, mas também antecipar ameaças futuras e reduzir os riscos de segurança.

Ao realizar regularmente testes de penetração de API, as empresas podem ficar à frente das ameaças em evolução, proteger dados confidenciais, diminuir a probabilidade de violações de dados e manter a confiança do cliente em seus serviços.

Se a sua empresa estiver procurando uma equipe profissional de pentest para melhorar a postura de segurança das suas APIs, entre em contato com nossos especialistas hoje mesmo.

Perguntas frequentes