Os 10 principais riscos de segurança de API do OWASP: A edição 2023 finalmente chegou
As interfaces de programação de aplicações (APIs) atuais permitem integração rápida e flexível entre praticamente qualquer software, dispositivo ou fonte de dados. As APIs atendem a uma ampla variedade de funcionalidades e atuam como uma base para inovação e transformação digital.
As APIs também se tornaram o padrão de fato para desenvolver e conectar aplicações modernas, especialmente com a crescente mudança para arquiteturas baseadas em microsserviços. É importante proteger adequadamente as APIs porque elas servem como cola digital entre os sistemas.
Cada uma dessas chamadas de API pode potencialmente abrir brechas de segurança e criar riscos de privacidade, desde má validação de dados, erros de configuração e falhas de implementação até falta de integração entre componentes de segurança. É importante observar isso ao abordar as vulnerabilidades definidas nos 10 principais riscos de segurança de API do Open Web Application Security Project (OWASP).
Em 5 de junho de 2023, o OWASP emitiu a primeira grande atualização para sua lista inicial, que foi lançada em 2019. Vamos analisar as mudanças e ver quais fatores-chave estão influenciando as vulnerabilidades atuais das APIs para que você possa estar mais bem informado sobre sua jornada para proteger suas APIs.
"Os 10 principais riscos de segurança de API do OWASP"
OWASP é uma organização não governamental que cria documentos de conscientização sobre segurança com base no feedback da comunidade e na avaliação de especialistas, incluindo contribuições da Akamai. Esses documentos descrevem os tipos mais comuns de vulnerabilidades encontradas nas organizações atualmente e são um excelente recurso para qualquer pessoa envolvida com APIs, de desenvolvedores a CISOs.
O OWASP publica um documento separado dos 10 principais riscos de segurança de API, além de suas outras listas dos 10 principais, para enfatizar que API Security, requer uma abordagem única. O Projeto de segurança de API OWASP "foca em estratégias e soluções para entender e mitigar as vulnerabilidades e os riscos de segurança exclusivos de... APIs."
As diferenças
Vamos revisar o que há de diferente entre as edições de 2019 e 2023 (Figura 1).
Fig. 1: As mudanças nos 10 principais riscos de segurança de API do OWASP de 2023
De acordo com as notas da versão de 2023:
O OWASP Top 10 API Security Risks 2023 é um documento de conscientização voltado para o futuro para um setor em ritmo acelerado. Ele não substitui outros Top 10s. Nesta edição:
- Combinamos exposição excessiva de dados e atribuição em massa com foco na causa raiz comum: falhas na validação de autorização no nível da propriedade do objeto.
- Colocamos mais ênfase no consumo de recursos, focando demais no ritmo em que eles se esgotam.
- Criamos uma nova categoria "Acesso irrestrito a fluxos de negócios sensíveis" para lidar com novas ameaças, incluindo a maioria daquelas que podem ser mitigadas usando limitação de taxa.
- Adicionamos o "Consumo inseguro de APIs" para abordar algo que começamos a ver: os invasores começaram a procurar os serviços integrados de um alvo para comprometê-los, em vez de atingir diretamente as APIs de seu alvo. Este é o momento certo para começar a conscientização sobre esse risco crescente.
O que há de novo, o que está na moda e o que está fora
NOVO | API3:2023 | Autorização corrompida no nível da propriedade de objeto
O OWASP combinou as antigas categorias de Exposição excessiva de dados e atribuição em massa na nova Autorização corrompida no nível de propriedade de objeto (BOPLA), com foco na causa raiz comum: falhas na validação de autorização no nível da propriedade do objeto.
A diferença entre (BOLA) e BOPLA é que BOLA se refere a um objeto inteiro, enquanto BOPLA se refere a uma propriedade dentro de um objeto (Figura 2).
Fig. 2: BOPLA se refere a uma propriedade dentro de um objeto
Tanto o OWASP quanto a Akamai continuam a ver grandes riscos no nível do objeto, o que explica por que o BOLA continua sendo o primeiro e mais crítico risco de segurança de API a ser observado.
No entanto, mergulhando um nível mais fundo e olhando para o nível de propriedade do objeto, há um risco adicional de compartilhamento excessivo de informações ou de fornecer permissão a propriedades específicas que podem ser modificadas ou excluídas quando esse não deveria ser o caso.
Estar coberto pelo BOLA não significa que você está coberto pelo BOPLA, e combinar atribuição em massa e exposição excessiva de dados em uma única categoria enfatiza a atenção exigida pelos desenvolvedores de API para as propriedades de um objeto.
Essa distinção é importante para quem está escolhendo um produto de segurança de API porque é preciso ter certeza de que o produto cobre os dois tipos de ataque.
IN | API6:2023 | Falsificação de solicitação do lado do servidor
O OWASP reduziu o risco de segurança de injeção e, ao fazê-lo, removeu-o do top 10 e abriu caminho para que SSRF (Server-Side Request Forgery, falsificação de solicitação no lado do servidor) fosse adicionado.
SSRF é um tipo de ataque que explora uma vulnerabilidade em um aplicativo Web ou API, que permite que um invasor faça solicitações não autorizadas do servidor para outros sistemas internos ou externos.
Aqui estão alguns motivos potenciais pelos quais o OWASP escolheu fazer essa mudança:
- As APIs são mais vulneráveis a ataques SSRF porque dependem de tecnologias modernas, como Kubernetes e Docker, que dependem de protocolos de comunicação baseados em API HTTPS.
- Com tecnologias como Webhooks, integrações SSO e busca/redirecionamento de arquivos URL por meio de pontos de extremidade de API, há uma oportunidade para os agentes de ameaças aplicarem SSRF.
Um mergulho mais profundo
Para um mergulho mais profundo nos ataques SSRF, leia o artigo de Mike Elissen Suas APIs estão permitindo ataques de falsificação de solicitação no servidor (SSRF).
OUT | API8:2019 | Injection
Remover os ataques de injeção da lista foi uma medida ousada e controversa dentro da comunidade de segurança de API, mas há uma ameaça reduzida de ataques de injeção em pontos de extremidade de API.
A injeção agora é essencialmente parte da API8:2023 | Configuração incorreta de segurança. A configuração de segurança adequada deve incluir aplicativos da Web e mecanismos de proteção de API, que devem verificar e evitar injeções por padrão.
GraphQL está crescendo como uma tecnologia API. Ele é, em sua essência, uma linguagem de consulta que pode reabrir a porta para um aumento nos ataques de injeção, portanto, os desenvolvedores de API que dependem do GraphQL devem continuar vigilantes.
NOVO | API4:2023 | Consumo irrestrito de recursos
A lista original se concentrava especificamente na compreensão do risco de consumo de recursos que faz com que os pontos de extremidade da API fiquem sobrecarregados (e potencialmente indisponíveis), prejudicando a experiência do usuário.
Os pontos de extremidade da API hoje em dia precisam estar disponíveis, mas apenas estar disponíveis não é tudo. Implementar gateway de API, balanceamento de carga ou controles de limitação de taxa é um passo na direção certa.
Nos últimos anos, vemos uma grande mudança na "economia do uso de API". Essa categoria atualizada tem como objetivo criar consciência sobre esse aspecto, que continuará a crescer com integrações de API de terceiros.
NOVO | API6:2023 | Acesso irrestrito a fluxos comerciais confidenciais
Outra nova adição é API6:2023 Acesso irrestrito a fluxos comerciais confidenciais. Esta categoria finalmente codificou o que torna a segurança tão especial: pensar mais como um ator de ameaça e ver onde podem estar os ganhos potenciais.
A tecnologia (a API) é apenas uma forma de executar a lógica de negócios, e ter maneiras de contornar ou alterar essa lógica de negócios por meio da tecnologia é indesejado e pode levar a complicações.
O OWASP compartilhou exemplos específicos de como essas complicações podem ser evitadas, mas esse risco de segurança é muito específico para a lógica de negócios que seus pontos de extremidade de API suportam.
Desenvolvedores de API: Exemplo
Recentemente, Mike Elissen conversou com desenvolvedores de API em um serviço de streaming. Para atrair um novo público, esse serviço de streaming ofereceu um teste gratuito de 30 dias para novos usuários que compartilhassem informações de cartão de crédito.
No entanto, a lógica de negócios analisava apenas endereços de e-mail exclusivos para novas inscrições. Um novo endereço de e-mail poderia facilmente acessar um novo teste usando as mesmas informações de cartão de crédito, o que poderia levar os usuários que criam novas contas a cada mês a usar o serviço gratuitamente por tempo indeterminado.
NOVO | API10:2023 | Consumo inseguro de APIs
Como o consumo de API de terceiros está crescendo rapidamente, as APIs muitas vezes precisam se integrar e se comunicar com diferentes serviços internos e externos (de terceiros), enviando e recebendo dados.
É importante seguir as regras "básicas" de segurança também nesses casos, e pode ser complicado para os produtos de segurança detectar vulnerabilidades e defender-se proativamente neste espaço.
O OWASP inclui uma gama de sugestões no seu documento, tanto gerais como específicas de API, tais como:
- Seguir as instruções com cuidado. Incorporar essa supervisão na lógica de negócios, bem como adicionar soluções de segurança que monitoram e inspecionam continuamente os fluxos de tráfego.
- Não confiar simplesmente em APIs de terceiros, mesmo que elas tenham uma boa reputação. Criar defesas e limites em seus aplicativos e pontos de extremidade de API.
A Akamai pode ajudar com segurança de API
As organizações e seus fornecedores de segurança devem trabalhar em conjunto, alinhando pessoas, processos e tecnologias para estabelecer uma defesa sólida contra os riscos de segurança descritos no "Os 10 principais riscos de segurança de API do OWASP".
A Akamai fornece soluções de segurança líderes do setor, especialistas altamente experientes e o Akamai Connected Cloud,que coleta insights de milhões de ataques a aplicações da Web, bilhões de solicitações de bots e trilhões de solicitações de API todos os dias. As soluções de segurança de API e aplicações da Web da Akamai ajudarão a proteger sua organização contra as formas mais avançadas de aplicações da Web, negação de serviço distribuída e ataques baseados em API.
Akamai + Neosec
A nova versão do OWASP coincide com nossa recente aquisição do Neosec. A solução de segurança de API da Neosec complementará o portfólio líder de mercado de aplicações e segurança de API da Akamai, ampliando radicalmente a visibilidade da Akamai no cenário de ameaças de API em rápido crescimento.
A combinação foi projetada para facilitar a proteção de suas APIs pelos clientes, ajudando-os a descobrir todas as suas APIs, avaliar seus riscos e responder a vulnerabilidades e ataques.
Saiba mais
Saiba mais sobre as soluções de segurança de API da Akamai e nossa aquisição da Neosec.
Parabéns e obrigado, OWASP!
Criar consciência de segurança exige um enorme esforço da comunidade e agradecemos o OWASP por liderar este projeto. Agradecimentos especiais a Erez Yallon, Inon Shkedy e Paulo Silva por todo o excelente trabalho na edição de 2023.
Também queremos agradecer a todos os colaboradores, particularmente a Maxim Zavodchik e a Mike Elissen, ambos da Akamai, por participarem desse projeto e educarem a comunidade de desenvolvedores em geral sobre segurança de API.
Informações adicionais sobre APIs
A Akamai rastreia o uso de APIs e a quantidade de tráfego de APIs como parte de seus relatórios State of the Internet (SOTI). Leia os relatórios SOTI anteriores para obter mais informações e procure novos relatórios SOTI a cada trimestre.
Recursos adicionais
Série de vídeos: Fundamentos da segurança de API
Post do blog: O que as novas alterações propostas no OWASP API Security Top 10 significam para você
