Os 10 principais riscos de segurança de API da OWASP

Ao tentar aprimorar a segurança de APIs, pode ser difícil saber por onde começar. Sua equipe talvez tenha dúvidas sobre o que é uma vulnerabilidade “crítica” ou “não crítica” e quais ferramentas implementar para mitigar os riscos mais graves para aplicações de back-end (ou seja, servidores) e outros sistemas que usam APIs.

O setor de cibersegurança responde a essas perguntas criando frameworks que oferecem insights baseados em pesquisas sobre quais riscos priorizar e como lidar com eles. Um dos desenvolvimentos mais recentes é o OWASP API Top 10, um framework para proteger suas APIs.

O que é o OWASP API Top 10

Há mais de uma década, a fundação OWASP oferece recomendações de segurança para organizações. Sua iniciativa mais conhecida é o projeto OWASP Top 10, criado em 2003 e atualizado recentemente, em 2021.

A primeira lista de segurança de APIs da OWASP foi lançada em 2019. A OWASP decidiu publicá-la por reconhecer a importância das APIs e os riscos cada vez maiores que elas representam para a postura de segurança dos aplicativos móveis, SaaS e web de hoje.

Por que usar o OWASP API Security Top 10?

Hoje, as empresas de software não conseguem inovar sem APIs. Elas são a base de inúmeros aplicativos, permitindo que integrem e compartilhem dados e funcionalidades com facilidade com outras entidades — como terceiros e outras equipes internas de desenvolvimento. A essência de uma API é justamente permitir a troca fácil de dados e a interoperabilidade. Infelizmente, isso também facilita para que um invasor exponha a lógica do aplicativo e os dados confidenciais disponibilizados por uma API. Como essas APIs costumam ser públicas, o risco de serem usadas por agentes mal-intencionados é considerável.

Segurança de aplicações web versus segurança de APIs

Por que a OWASP precisou publicar uma lista separada das 10 principais vulnerabilidades de APIs? Porque APIs e aplicações web, embora muitas vezes dependam umas das outras, são tecnologias diferentes e podem trazer tipos distintos de risco.

Segurança de aplicações web

As aplicações web tradicionais têm pontos de entrada principalmente em dois lugares: no lado do cliente e no lado do servidor. As maiores ameaças às aplicações web geralmente estão relacionadas a falhas em uma dessas duas categorias.

Dois exemplos de vulnerabilidades do OWASP Top 10 em aplicações são a falha no controle de acesso, que permite que pessoas não autorizadas acessem o servidor, e as falhas criptográficas, que significam que os dados armazenados no servidor não são criptografados adequadamente.

Como podemos ver, esses dois tipos de risco estão diretamente relacionados ao servidor. Isso porque as aplicações web têm poucos pontos de entrada: os dados são processados no servidor, a página é renderizada no navegador do cliente, o usuário envia uma solicitação de volta e ela chega novamente ao servidor. É uma via simples de mão dupla. Embora agentes mal-intencionados possam adulterar qualquer parte desse processo, há poucos pontos de entrada.

Segurança de APIs

As APIs, por outro lado, oferecem uma superfície de ataque potencialmente ampla, pois expõem muitos endpoints que agentes mal-intencionados podem usar para acessar dados confidenciais. Os componentes de um mesmo aplicativo operam com APIs individuais que enviam e recebem dados de servidores. Um aplicativo pode ter vários pontos de entrada voltados para o cliente, todos passíveis de exploração por um invasor.

Como mencionamos, a própria natureza das APIs é expor dados. Quando funcionam como esperado, elas tornam os aplicativos muito mais eficientes, pois podem “conversar” com outros aplicativos e bancos de dados. Infelizmente, essa característica também torna os riscos de segurança de APIs especialmente prejudiciais para as empresas que as utilizam.

Os 10 principais riscos de segurança de APIs da OWASP, explicados

A lista de segurança de APIs da OWASP classifica as principais vulnerabilidades que podem comprometer a segurança do servidor da sua aplicação. Ela orienta suas equipes na escolha de soluções e serviços para reforçar a segurança das APIs e criar uma postura de segurança mais sólida de ponta a ponta em toda a organização.

Confira a lista completa e use os links para ir diretamente a cada seção:

1. Falha na autorização em nível de objeto

2. Falha na autenticação de usuário

3. Exposição excessiva de dados

4. Falta de recursos e limitação de taxa

5. Falha na autorização em nível de função

6. Atribuição em massa

7. Configuração incorreta de segurança

8. Injeção

9. Gerenciamento inadequado de ativos

10. Registro e monitoramento insuficientes

#1: Falha na autorização em nível de objeto

As APIs usam autorização em nível de objeto para garantir que somente os usuários certos acessem os dados disponibilizados por elas. Se esse mecanismo de controle de acesso falhar, os invasores poderão usar a API para divulgar, alterar ou destruir dados que não são deles ou aos quais não deveriam ter acesso.

#2: Falha na autenticação de usuário

Os endpoints e fluxos de autenticação de usuário são considerados vulneráveis quando a API não utiliza mecanismos de segurança adequados, como chaves de criptografia fortes, proteção contra ataques de preenchimento de credenciais ou senhas com hash robusto. Se um desenvolvedor não alternar as chaves ou configurar a autenticação por token, os invasores poderão obter as credenciais de outra pessoa e usá-las para acessar as APIs.

Por exemplo, algumas versões do GitLab não autorizam corretamente os pipelines agendados. Essa vulnerabilidade pode permitir que um usuário mal-intencionado execute um pipeline no contexto de outro usuário.

#3: Exposição excessiva de dados

Essa vulnerabilidade ocorre quando uma API fornece mais informações do que deveria, algo que os invasores podem explorar. Esse tipo de exposição de dados é comum porque os desenvolvedores costumam implementar APIs de forma genérica, sem limitar os endpoints. Em vez disso, é preciso definir com cuidado quais endpoints da API serão expostos e, por padrão, filtrar todos os demais.

Um exemplo é o Moodle, uma plataforma de aprendizagem. O Moodle tem uma funcionalidade para baixar tabelas que inclui os e-mails dos usuários, mesmo quando eles estão ocultos. Uma simples atualização corrige essa vulnerabilidade.

#4: Falta de recursos e limitação de taxa

Surgem vulnerabilidades quando as equipes de desenvolvimento não limitam o tamanho ou a quantidade de recursos que um cliente pode solicitar. Com tentativas ilimitadas para fazer a solicitação correta, os invasores podem realizar ataques de força bruta ou de negação de serviço.

Por exemplo, o middleware `express-brute` tem um pacote vulnerável à evasão da limitação de taxa. A contagem incorreta das solicitações enviadas permite que um invasor burle o mecanismo de limitação de taxa.

#5: Falha na autorização em nível de função

Quando um sistema de controle de acesso é configurado incorretamente, os invasores podem obter acesso não autorizado aos endpoints da API e usar os novos privilégios para explorá-los.

`github.com/matrix-org/gomatrixserverlib`, uma biblioteca Go com funções comuns necessárias para servidores Matrix, tem uma versão do pacote em que a função de análise do nível de poder pode falhar — fazendo com que os servidores Dendrite autorizem ou rejeitem eventos incorretamente. Essa vulnerabilidade pode deixar as organizações expostas a um ataque de negação de serviço (DoS).

#6: Atribuição em massa

Essa vulnerabilidade ocorre quando uma API vincula dados fornecidos pelo cliente a modelos de dados. Com isso, um cliente mal-intencionado pode modificar propriedades de objetos simplesmente adulterando campos voltados para o cliente.

Um exemplo é o laravel/framework, um framework de aplicações web. As versões afetadas desse pacote são vulneráveis à atribuição em massa quando a propriedade `fillable` não é usada nos modelos.

#7: Configuração incorreta de segurança

Esta categoria inclui vulnerabilidades causadas por configurações de segurança implementadas incorretamente. Veja alguns exemplos de configurações incorretas que podem afetar uma API:

• Falta de patches de segurança

• Recursos desnecessários ativados

• O sistema não usa Transport Layer Security (TLS) nem uma política de compartilhamento de recursos entre origens (CORS)

• Mensagens de erro que expõem informações confidenciais

O `typo3/cms`, um framework de gerenciamento de conteúdo gratuito e de código aberto, tem várias versões vulneráveis a uma configuração incorreta de segurança que pode permitir a criação de uma conta sem credenciais. Um usuário de back-end com os privilégios de acesso adequados pode explorar essa falha.

#8: Injeção

Agentes mal-intencionados realizam ataques de injeção enviando dados maliciosos ao sistema pela camada da API. Isso pode afetar APIs que não validam nem higienizam os dados. O `simple-git`, por exemplo, é vulnerável à injeção de comandos por meio da injeção de argumentos nas versões 3.3.0 e anteriores. A injeção de algumas opções do git permitia executar comandos arbitrários.

 #9: Gerenciamento inadequado de ativos

As equipes precisam entender a finalidade e a composição de cada API e documentar essas informações detalhadamente. Caso contrário, podem deixar de atualizar, corrigir ou desativar as APIs quando necessário. Uma API desatualizada é muito mais vulnerável a ataques do que uma atualizada.

#10: Registro e monitoramento insuficientes

Quando a equipe de segurança não conta com recursos adequados de registro e monitoramento, um invasor pode tentar acessar os sistemas repetidamente sem que ela perceba.

Dois passos para reforçar a segurança das APIs

Ao avaliar os riscos de APIs do OWASP Top 10, sua equipe pode tomar duas medidas para lidar com possíveis falhas de segurança: buscar vulnerabilidades e capacitar a equipe sobre os riscos de APIs.

Busca por vulnerabilidades em APIs

As equipes de segurança precisam buscar regularmente vulnerabilidades em APIs, usando tecnologia para avaliar o código de APIs de back-end, identificar riscos e corrigi-los. Usar um projeto reconhecidamente vulnerável para testar as técnicas de análise da equipe é uma maneira eficaz de garantir que essas atividades funcionem. Há diversos recursos com projetos desse tipo, inclusive a OWASP. 

Como buscar vulnerabilidades em APIs

A Snyk oferece vários recursos para ajudar sua equipe a analisar a segurança de APIs. O Snyk Code é uma ótima opção para analisar o código das suas APIs de back-end e encontrar problemas de injeção, falha na autenticação de usuário, exposição excessiva de dados e outras questões de segurança. O Snyk IaC ajuda a identificar configurações incorretas de segurança (risco nº 7 da OWASP para APIs) ao configurar a infraestrutura para implantar contêineres ou funções sem servidor na nuvem.

Capacite sua equipe sobre as vulnerabilidades do OWASP API Top 10

As equipes também precisam ter conhecimentos práticos sobre o OWASP Top 10. Quando entendem de fato as causas de cada tipo de vulnerabilidade, é menos provável que contribuam para esses riscos e mais provável que ajudem a corrigi-los.

Além de oferecer oportunidades de aprendizado sobre vulnerabilidades comuns, sua organização também precisa criar políticas de segurança sólidas e capacitar os desenvolvedores para colocá-las em prática com treinamentos práticos. O Snyk Learn oferece conteúdo útil sobre vários temas de segurança, incluindo vulnerabilidades de APIs. Ao compreenderem as boas práticas de segurança, os desenvolvedores podem melhorar a postura geral de segurança com codificação segura, maior adesão e correções mais rápidas.

Como a Snyk ajuda na segurança de APIs

A Snyk não só oferece recursos para ajudar as organizações a usar APIs mais seguras, como também disponibiliza soluções de segurança de aplicações e da nuvem. Além disso, oferecemos às equipes materiais educativos sobre vulnerabilidades comuns em diversas linguagens e frameworks, como Java.

Nosso objetivo é oferecer recursos shift-left, fáceis de usar para desenvolvedores, que protejam todo o ciclo de vida de desenvolvimento de software (SDLC) sem comprometer a agilidade. Fale com a gente e agende uma demonstração hoje mesmo.