Você deve conhecer a Cloudflare como a empresa que alimenta quase 20% da web. Mas alimentar e proteger sites e conteúdo estático é apenas uma fração do que fazemos. Na verdade, bem mais da metade do tráfego dinâmico em nossa rede não consiste em páginas web, mas em tráfego de interfaces de programação de aplicativos (APIs), a infraestrutura que faz a tecnologia funcionar. Este blog apresenta e é um complemento ao Relatório sobre segurança de APIs para 2024, onde detalhamos exatamente como estamos protegendo nossos clientes e o que isso significa para o futuro da segurança de APIs. Ao contrário de outros relatórios sobre APIs do setor, nosso relatório não é baseado em pesquisas de usuários, mas sim em dados reais de tráfego.
Se houver apenas uma coisa que você possa aprender com nosso relatório deste ano, é esta: muitas organizações não possuem inventários de APIs precisos, mesmo quando acreditam que podem identificar corretamente o tráfego de APIs. A Cloudflare ajuda as organizações a descobrir todas as suas APIs públicas usando duas abordagens. Primeiro, os clientes configuram nossa ferramenta de descoberta de APIs para monitorar a identificação de tokens presentes em seu tráfego de APIs conhecido. Em seguida, usamos um modelo de aprendizado de máquina que verifica não apenas essas chamadas de API conhecidas, mas todas as solicitações HTTP, identificando o tráfego de APIs que pode não estar contabilizado. A diferença entre essas abordagens é impressionante: encontramos 30,7% mais endpoints de API por meio de descoberta baseada em aprendizado de máquina do que a abordagem auto-relatada, sugerindo que quase um terço das APIs são “APIs ocultas” e podem não estar devidamente inventariadas e protegidas.
Continue lendo para obter mais informações e destaques em nosso relatório inaugural sobre segurança de APIs. No relatório completo, você encontrará estatísticas atualizadas sobre as ameaças que vemos e prevenimos, juntamente com nossas previsões para 2024. Prevemos que a falta de foco na segurança de APIs nas organizações levará ao aumento da complexidade e à perda de controle, além disso, o maior acesso à IA generativa levará a mais riscos de APIs. Também prevemos um aumento nos ataques à lógica de negócios de APIs em 2024. Por último, todos os riscos acima exigirão uma governança crescente em torno da segurança de APIs.
Superfícies de ataque ocultas
Como as páginas web e as APIs são diferentes? As APIs são uma maneira rápida e fácil para os aplicativos recuperarem dados em segundo plano ou solicitarem que o trabalho seja feito a partir de outros aplicativos. Por exemplo, qualquer um pode escrever um aplicativo meteorológico sem ser meteorologista: um desenvolvedor pode escrever a estrutura da página ou aplicativo móvel e solicitar a previsão do tempo a uma API meteorológica usando a localização do usuário. É importante ressaltar que a maioria dos usuários finais não sabe que os dados foram fornecidos pela API meteorológica e não pelo proprietário do aplicativo.
Embora as APIs sejam a infraestrutura crítica da internet, elas também estão sujeitas a abusos. Por exemplo, falhas na autenticação e autorização de APIs na Optus levaram um agente de ameaça a oferecer 10 milhões de registros de usuários para venda, e agências governamentais alertaram sobre esses ataques exatos de APIs. Os desenvolvedores de uma organização geralmente criam APIs voltadas para a internet, usadas para que seus próprios aplicativos funcionem com mais eficiência, mas cabe à equipe de segurança proteger essas novas interfaces públicas. Se o processo de documentar APIs e levá-las ao conhecimento da equipe de segurança não estiver claro, elas se tornarão APIs ocultas, operando em produção, mas sem o conhecimento da organização. É aqui que o desafio da segurança começa a surgir.
Para ajudar os clientes a resolver esse problema, lançamos o API Discovery. Quando apresentamos nossa versão mais recente, mencionamos como poucas organizações possuem inventários de API precisos. Às vezes, as equipes de segurança são forçadas a adotar uma abordagem de “enviar e-mail e perguntar” para criar um inventário e, ao fazer isso, as respostas ficam imediatamente obsoletas no próximo lançamento de aplicativo, quando as APIs mudam. Melhor é rastrear as alterações de APIs por alterações na base de código, acompanhando os novos lançamentos. No entanto, isso ainda tem a desvantagem de apenas inventariar código mantido ativamente. Os aplicativos legados podem não receber novos lançamentos, apesar de receberem tráfego de produção.
A abordagem da Cloudflare para gerenciamento de APIs envolve a criação de um inventário de APIs abrangente e preciso usando uma combinação de descoberta de APIs baseada em aprendizado de máquina e inspeção de tráfego de rede. Isso é parte integrante do nosso produto API Gateway, onde os clientes podem gerenciar seus endpoints voltados para a internet e monitorar a integridade das APIs. O API Gateway também permite que os clientes identifiquem o tráfego de APIs usando identificadores de sessão (normalmente um cabeçalho ou cookie), o que ajuda a identificar especificamente o tráfego de APIs para o processo de descoberta.
Conforme observado anteriormente, nossa análise revela que mesmo clientes experientes muitas vezes ignoram partes significativas de seu tráfego de APIs. Ao comparar a descoberta de APIs baseada em sessão (usando sessões de API para identificar o tráfego) com nossa descoberta de APIs baseada em aprendizado de máquina (analisando todo o tráfego de entrada), descobrimos que esta última descobre em média 30,7% mais endpoints! Sem uma análise ampla de tráfego, você pode perder quase um terço do seu inventário de APIs.
Se você não é cliente da Cloudflare, ainda pode começar a criar um inventário de APIs. As APIs são normalmente catalogadas em um formato padronizado chamado OpenAPI, e muitas ferramentas de desenvolvimento podem criar arquivos de esquema formatados em OpenAPI. Se você tiver um arquivo com esse formato, poderá começar a criar um inventário de APIs coletando esses esquemas. Aqui está um exemplo de como você pode extrair os endpoints de um arquivo de esquema, supondo que você tenha um arquivo formatado OpenAPI v3 chamado `my_schema.json`:
A menos que você esteja gerando esquemas OpenAPI e monitorando o inventário de APIs desde o início do processo de desenvolvimento de seu aplicativo, provavelmente estão faltando alguns endpoints em seu inventário de APIs de aplicativos de produção.
import json
import csv
from io import StringIO
# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
schema = json.load(file)
# Prepare CSV output
output = StringIO()
writer = csv.writer(output)
# Write CSV header
writer.writerow(["Server", "Path", "Method"])
# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
url = server['url']
for path, methods in schema['paths'].items():
for method in methods.keys():
writer.writerow([url, path, method])
# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)Limites de taxa precisos minimizam o potencial de ataques
Quando se trata de parar o abuso, a maioria dos profissionais pensam primeiro na limitação de taxa. Implementar limites em suas APIs é uma ferramenta valiosa para manter o abuso sob controle e evitar sobrecarga acidental da origem. Mas como saber se escolheu a abordagem correta de limitação de taxa? As abordagens podem variar, mas geralmente se resumem ao código de erro escolhido e à base para o próprio valor limite.
Para algumas APIs, os profissionais configuram erros de limitação de taxa para responder com HTTP 403 (proibido), enquanto outros respondem com HTTP 429 (excesso de solicitações). Usar HTTP 403 parece inofensivo até você perceber que outras ferramentas de segurança também estão respondendo com códigos 403. Quando você está sob ataque, pode ser difícil decifrar quais ferramentas são responsáveis por quais erros/bloqueios.
Alternativamente, se você utilizar o HTTP 429 para seus limites de taxa, os invasores saberão instantaneamente que sua taxa foi limitada e poderão “navegar” abaixo do limite sem serem detectados. Isso pode ser aceitável se você estiver apenas limitando solicitações para garantir que seu back-end permaneça operacional, mas pode revelar suas estratégias aos invasores. Além disso, os invasores podem “escalar” para mais clientes de API para efetivamente fazer solicitações acima do limite de taxa.
Existem prós e contras em ambas as abordagens, mas descobrimos que, de longe, a maioria das APIs responde com o HTTP 429, de todas as mensagens de erro 4xx e 5xx (quase 52%).
E quanto à lógica da regra de limite de taxa em si, e não apenas ao código de resposta? Implementar limites de solicitação em endereços de IP pode ser tentador, mas recomendamos que você baseie o limite em um ID de sessão como prática recomendada e só retorne ao endereço de IP (ou IP + impressão digital JA3) quando os IDs de sessão não estiverem disponíveis. Definir limites de taxa para sessões de usuários em vez de IPs identificará com segurança seus usuários reais e minimizará falsos positivos devido ao espaço de IP compartilhado. O Advanced Rate Limiting da Cloudflare e a proteção volumétrica contra abuso do API Gateway facilitam a aplicação desses limites, traçando o perfil do tráfego de sessão em cada endpoint de API e fornecendo soluções com um clique para configurar os limites de taxa por endpoint.
Para encontrar os valores para seus limites de taxa, o Cloudflare API Gateway calcula as estatísticas de solicitações por sessão para você. Sugerimos um limite observando a distribuição de solicitações por sessão em todas as sessões de suas APIs, conforme identificado pelo identificador de sessão de APIs configurado pelo cliente. Em seguida, calculamos níveis p estatísticos, que descrevem as taxas de solicitação para diferentes coortes de tráfego, para p50, p90 e p99 nesta distribuição e usamos a variação da distribuição para chegar a um limite recomendado para cada endpoint em seu inventário de APIs. A recomendação pode não corresponder aos níveis p, o que é uma distinção importante e uma razão para não utilizar apenas os níveis p. Junto com a recomendação, o API Gateway informa aos usuários sobre nossa confiança na recomendação. Geralmente, quanto mais sessões de APIs conseguirmos coletar, mais confiantes estaremos na recomendação.
Ativar um limite de taxa é tão simples quanto clicar no link "criar regra", e o API Gateway automaticamente levará seu identificador de sessão para a página avançada de criação de regras de limite de taxa, garantindo que suas regras tenham precisão exata para se defender contra ataques e minimizar falsos positivos em comparação com limites tradicionais excessivamente amplos.
APIs também são vítimas de ataques a aplicativos web
As APIs não estão imunes a ataques normais do estilo Top 10 do OWASP, como injeção de SQL. O corpo das solicitações de API também pode ser usado como uma entrada de banco de dados, assim como uma entrada de formulário de página web ou argumento de URL. É importante garantir que você tenha um firewall de aplicativos web (WAF) que também proteja o tráfego de APIs para se defender contra esses estilos de ataques.
Na verdade, quando analisamos as regras gerenciadas pelo WAF da Cloudflare, os ataques de injeção foram o segundo vetor de ameaça mais comum realizado em APIs que a Cloudflare observou. A ameaça mais comum foi a anomalia HTTP. Exemplos de anomalias HTTP incluem nomes de métodos malformados, caracteres de bytes nulos em cabeçalhos, portas não padrão ou comprimento de conteúdo zero com uma solicitação POST. Aqui estão as estatísticas sobre as outras principais ameaças contra APIs que observamos:
As falhas na autenticação e na autorização não aparecem no gráfico. As falhas na autenticação e na autorização ocorrem quando uma API não consegue verificar se a entidade que envia as solicitações de informações para uma API realmente tem permissão para solicitar esses dados ou não. Também podem acontecer quando os ataques tentam falsificar credenciais e inserir permissões menos restritas em suas credenciais existentes (válidas) que possuem permissões mais restritas. O OWASP categoriza esses ataques de algumas maneiras diferentes, mas as categorias principais são ataques de Falha de autorização no nível do objeto (BOLA) e Falha na autorização no nível de função (BFLA).
A causa raiz de um ataque BOLA/BFLA bem-sucedido está em uma API de origem que não verifica a propriedade adequada dos registros do banco de dados em relação à identidade que solicita esses registros. Rastrear esses ataques específicos pode ser difícil, pois a estrutura de permissão pode simplesmente estar ausente, ser inadequada ou ser implementada incorretamente. Você consegue ver o problema do ovo e da galinha aqui? Seria fácil parar estes ataques se soubéssemos a estrutura de permissão adequada, mas se nós ou os nossos clientes soubéssemos a estrutura de permissão adequada ou pudéssemos garantir a sua aplicação, os ataques não seriam bem sucedidos para começar. Fique atento aos futuros lançamentos de recursos do API Gateway, onde usaremos nosso conhecimento das normas de tráfego de APIs para sugerir automaticamente políticas de segurança que destaquem e interrompam ataques BOLA/BFLA.
Aqui estão quatro maneiras de preencher brechas de autenticação que podem existir para suas APIs, mesmo se você não tiver uma política de autorização refinada disponível:
Primeiro, impor a autenticação em cada API acessível publicamente, a menos que haja uma exceção aprovada pela empresa. Procure tecnologias como mTLS e JSON Web Tokens.
Limitar a velocidade das solicitações de APIs aos seus servidores para retardar possíveis invasores.
Bloquear volumes anormais de saída de dados confidenciais.
Impedir que invasores ignorem sequências legítimas de solicitações de API.
As APIs, surpreendentemente, são dirigidas por humanos, não mais por máquinas
Se você conhece a tecnologia desde os dias pré-smartphone, quando menos pessoas estavam habitualmente on-line, pode ser tentador pensar nas APIs como sendo usadas apenas para comunicação máquina a máquina em algo como um processo de trabalho em lote noturno. No entanto, a realidade é bem diferente. Como já discutimos, muitos aplicativos web e móveis são alimentados por APIs, que facilitam tudo, desde autenticação até transações e entrega de arquivos de mídia. À medida que as pessoas usam esses aplicativos, há um aumento correspondente no volume de tráfego da APIs.
Podemos ilustrar isso analisando os padrões de tráfego de APIs observados durante datas comemorativas, quando as pessoas se reúnem com amigos e familiares e passam mais tempo socializando pessoalmente e menos tempo on-line. Registramos o seguinte gráfico de tráfego mundial de APIs com datas comemorativas e promoções comuns. Observe como o tráfego atinge o pico na Black Friday e na Cyber Monday em torno do nível de +10% quando as pessoas fazem compras on-line, mas depois o tráfego diminui nas festividades dos dias de Natal e Ano Novo.
Esse padrão se assemelha muito ao que observamos no tráfego HTTP normal. Está claro que as APIs não são mais apenas o domínio dos processos automatizados, mas estão intrinsecamente ligadas aos comportamentos humanos e às tendências sociais.
Recomendações
Não existe solução mágica para segurança holística de APIs. Para obter o melhor efeito, a Cloudflare recomenda quatro estratégias para aumentar a postura de segurança de APIs:
Combinar desenvolvimento de aplicativos, visibilidade, desempenho e segurança de APIs com um plano de controle unificado que pode manter um inventário de APIs atualizado.
Usar ferramentas de segurança que utilizam tecnologias de aprendizado de máquina para liberar recursos humanos e reduzir custos.
Adotar um modelo de segurança positivo para suas APIs (veja abaixo uma explicação sobre modelos de segurança positivos e negativos).
Medir e melhorar o nível de maturidade de APIs da sua organização ao longo do tempo (veja também abaixo uma explicação sobre o nível de maturidade de APIs).
O que queremos dizer com modelo de segurança “positivo” ou “negativo”? Num modelo negativo, as ferramentas de segurança procuram sinais conhecidos de ataque e tomam medidas para impedir esses ataques. Em um modelo positivo, as ferramentas de segurança procuram solicitações válidas e apenas as deixam passar, bloqueando todo o resto. As APIs costumam ser tão estruturadas que modelos de segurança positivos fazem sentido para os mais altos níveis de segurança. Você também pode combinar modelos de segurança, como usar um WAF no sentido de modelo negativo e usar a validação de esquema de API no sentido de modelo positivo.
Esta é uma maneira rápida de avaliar o nível de maturidade de segurança de APIs da sua organização ao longo do tempo. Organizações iniciantes começarão montando seu primeiro inventário de APIs, não importa quão incompleto seja. Organizações mais maduras se esforçarão para obter precisão no inventário e nas atualizações automáticas de APIs. As organizações mais maduras aplicarão ativamente verificações de segurança em um modelo de segurança positivo em suas APIs, aplicando o esquema de API, a autenticação válida e verificando o comportamento em busca de sinais de abuso.
Previsões
Para encerrar, nossas quatro principais previsões para 2024 e os anos seguintes:
Aumento da perda de controle e complexidade: entrevistamos profissionais da área de segurança e gerenciamento de APIs e 73% responderam que os requisitos de segurança interferem em sua produtividade e inovação. Juntamente com aplicativos cada vez mais extensos e inventários imprecisos, os riscos e a complexidade das APIs aumentarão.
Acesso mais fácil à IA, levando a mais riscos de APIs: o aumento da IA generativa traz riscos potenciais, incluindo APIs de modelos de IA vulneráveis a ataques, mas também desenvolvedores que enviam códigos escritos por IA com erros. A Forrester prevê que, em 2024, sem as proteções adequadas, “pelo menos três violações de dados serão publicamente atribuídas a códigos inseguros gerados por IA, seja devido a falhas de segurança no próprio código gerado ou a vulnerabilidades em dependências sugeridas por IA”.
Aumento de ataques de fraude baseados em lógica de negócios: os fraudadores profissionais administram suas operações como uma empresa e têm custos como qualquer outra. Prevemos que os invasores executarão bots fraudulentos contra APIs com eficiência ainda mais do que nos anos anteriores.
Governança crescente: a primeira versão do PCI DSS que aborda diretamente a segurança de APIs entrará em vigor em março de 2024. Verifique os requisitos específicos do seu setor com o departamento de auditoria para se preparar para os requisitos assim que entrarem em vigor.
Se tiver interesse no relatório completo, você pode baixar o Relatório sobre segurança de APIs de 2024 aqui, que inclui detalhes completos sobre nossas recomendações.
Cloudflare API Gateway é nossa solução de segurança de APIs e está disponível para todos os clientes Enterprise. Se você não estiver inscrito no API Gateway, clique aqui para visualizar os resultados iniciais do API Discovery e iniciar uma avaliação no painel da Cloudflare. Para saber como usar o API Gateway para proteger seu tráfego, clique aqui para ver nossos documentos de desenvolvimento e aqui para nosso guia de primeiros passos.