10 principais ameaças à API do OWASP

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Este documento descreve várias abordagens que podem ser usadas na Apigee para resolver vulnerabilidades de segurança identificadas pela OWASP. Para outras abordagens documentadas para a Apigee, consulte As 10 principais opções de mitigação da OWASP para 2021 no Google Cloud.

Introdução

A OWASP (link em inglês) é uma comunidade aberta dedicada a ajudar as organizações a desenvolver, comprar e manter aplicativos e APIs confiáveis. Pelo projeto de segurança de API do OWASP, o OWASP publica os riscos de segurança mais críticos para aplicativos da Web e APIs REST, além de fornecer recomendações para lidar com esses riscos.

Este documento aborda abordagens para proteção contra ataques comuns baseados em API, conforme identificado pelas dez principais ameaças à segurança de API da OWASP em 2019. Um tema comum nas principais ameaças destacadas pela lista mais recente é causado pelo posicionamento inadequado de controles de autenticação e autorização, como a dependência da filtragem de dados retornados por uma solicitação de API em apps clientes, usando o antipadrão de depender do app cliente consumidor para realizar a aplicação do controle de acesso.

Com o crescimento contínuo e rápido do ecossistema de APIs, os abusos e usos indevidos que resultam em exfiltração de dados por invasores estão se tornando um dos vetores de ataque mais comuns atualmente. A segurança continua sendo uma prioridade fundamental para a Apigee, com vários recursos novos, como o Advanced API Ops, que inclui recursos de detecção de anomalias. No entanto, projetar e implementar corretamente os recursos de segurança do Apigee é fundamental para reduzir a probabilidade de ataques bem-sucedidos às suas APIs.

Os aplicativos do consumidor devem ser considerados não confiáveis ou "públicos", já que você não controla a plataforma em que o app está sendo executado. Suponha que qualquer app público pode ser comprometido e será. Portanto, não é possível confiar neles para aplicar o controle de acesso (API1, API5), filtrar dados de resposta (API6) ou armazenar com segurança segredos do cliente (API2), como chaves de API ou tokens de acesso. Algumas recomendações surgem do exame do top 10 da OWASP de 2019:

  • Determine que tipo de apps clientes vai consumir suas APIs (SPA, dispositivos móveis ou baseados em navegador) e crie os padrões de autenticação, autorização e segurança adequados.
  • Sempre use fluxos OAuth ou OpenID Connect de "cliente público". É altamente recomendável usar o PKCE.
  • Pense na lógica de negócios do seu app, defina primeiro a especificação OpenAPI e crie proxies de API para filtrar todos os dados de resposta do back-end no Apigee. Nunca confie na lógica do código do app downstream para fazer isso.
  • Filtre todas as solicitações de dados que contêm PIIs específicas do usuário para permitir apenas dados do seu back-end que pertencem ao usuário solicitante.

API1:2019 Autorização quebrada no nível do objeto

Descrição da ameaça

A validação insuficiente da autorização de uma solicitação de acesso a objetos permite que um invasor realize uma ação não autorizada reutilizando um token de acesso. Essa ameaça é causada por uma configuração incorreta das validações de autorização. A Apigee oferece políticas VerifyApiKey, OAuth e JSON Web Token (JWT) que ajudam a proteger contra essa vulnerabilidade. No entanto, é fundamental que essas políticas sejam configuradas corretamente para evitar essa ameaça.

Para evitar essa ameaça, é importante que as equipes de desenvolvimento de aplicativos e segurança colaborem de perto. A autorização é um tema complexo por natureza, e uma autorização refinada eficaz exige um entendimento profundo da lógica de negócios do aplicativo.

Há dois aspectos principais a serem considerados do ponto de vista da implementação do Apigee:

  • Integridade do token de acesso
  • Aplicação do controle de acesso

Integridade do token de acesso

É fundamental validar se o token fornecido pelo cliente solicitante não foi adulterado usando o fluxo correto do OAuth ou do OpenID Connect com o mecanismo apropriado de validação ou assinatura de credenciais. A Apigee é compatível com todos os fluxos do OAuth usados com frequência.

As políticas de verificação de tokens de acesso da Apigee incluem:

Aplicação do controle de acesso

Depois que a validade do token de acesso é verificada, é fundamental implementar políticas de controle de acesso para avaliar cada solicitação de API recebida em relação aos direitos de acesso do token de autorização.

A Apigee oferece dois mecanismos principais para verificar e aplicar políticas de autorização:

  • Interno: usando fluxos condicionais para avaliar solicitações de acesso com base em declarações extraídas como variáveis de fluxo de um token de autorização
  • Delegado: usando um destaque de chamada de serviço para uma solução de gerenciamento de acesso de terceiros

A abordagem interna (ilustrada na figura acima) é recomendada quando o modelo de controle de acesso é relativamente simples. Por exemplo, se declarações extraídas de um token de acesso puderem ser usadas para avaliar e autorizar diretamente uma solicitação de objeto de API.

Use as variáveis de fluxo disponíveis para as políticas OAuth ou JWT para avaliar solicitações de acesso usando instruções de fluxo condicionais.

A abordagem delegada (ilustrada na figura acima) é recomendada quando as declarações extraídas de um token de acesso não podem ser usadas diretamente para autorizar uma solicitação de API a um objeto de back-end ou para tipos de fluxo OAuth mais complexos que exigem uma chamada separada a um servidor de autorização para receber um token de acesso.

Usando a política service callout, é possível solicitar uma decisão de política de autorização de um serviço de terceiros ou obter mais informações de declaração sobre o agente solicitante para tomar uma decisão de controle de acesso usando um fluxo condicional.

API2:2019 Autenticação de usuário inválida

Descrição da ameaça

Políticas de autenticação de usuários mal implementadas permitem que invasores se passem por usuários legítimos aproveitando falhas de implementação em implementações de autenticação. Alguns princípios de autenticação a serem considerados ao implementar abordagens de autenticação incluem:

  • Sempre autentique o user agent (o app) e o usuário solicitante
  • Use padrões de autenticação e autorização delegadas e evite transmitir senhas diretamente em uma solicitação de API.
  • Sempre valide a assinatura das credenciais de acesso e verifique se todas as credenciais usadas têm um tempo de expiração definido.
  • Evite ataques de força bruta definindo cotas e usando o Apigee Sense para detectar e responder a ataques de força bruta impulsionados por bots.

Em um paradigma de fora para dentro, o design da API é criado com base nos casos de uso dos consumidores para os dados, em vez da estrutura dos dados atuais nos sistemas de back-end, e a segurança é um elemento essencial ao criar APIs para consumidores externos. Tradicionalmente, os sistemas de back-end não são criados com implementações de autenticação suficientemente fortes para exposição a redes públicas. É aqui que o Apigee, junto com uma solução de gerenciamento de identidade e acesso, pode oferecer soluções eficientes para proteção contra essa ameaça.

Há alguns elementos importantes a serem considerados aqui, e ambos serão abordados nas seções a seguir:

  • Design de segurança: aproveite ao máximo os recursos da Apigee para implementar padrões de autenticação.
  • Governança: garantir que o uso correto dos padrões de autenticação projetados seja consistente em todos os produtos de API publicados.
  • Segurança operacional: capacidade de detectar comportamentos suspeitos ou anômalos e tentativas de burlar ou usar força bruta em proxies de API autenticados.

Design de segurança

O objetivo do design de segurança é implementar corretamente fluxos de autenticação e integração com ferramentas de identidade de terceiros. O design de segurança é uma fase crítica, que começa com a compreensão do tipo certo de fluxo de autenticação delegada a ser usado com base no tipo de app que vai consumir seus endpoints de API. A próxima etapa é definir, com sua equipe de identidade, os padrões de integração a serem implementados com sua solução de identidade.

As RFCs OpenID Connect e OAuth oferecem um grande número de fluxos delegados de autenticação e autorização, bem como atores envolvidos nesses fluxos. Esse é um tema complexo, e não é surpreendente que a autenticação quebrada seja uma das principais ameaças de API da OWASP. Fornecer um guia abrangente sobre a implementação correta de padrões de identidade está fora do escopo deste documento. No entanto, a Apigee tem muitos recursos adicionais para entender melhor os fluxos do OAuth, como este e-book e webcast, além de um exemplo de implementação.

Políticas de autenticação

As políticas da Apigee que ajudam a resolver problemas de identidade e autenticação incluem:

  • Verificar ou gerar tokens de acesso, tokens de atualização ou tokens de fluxo de resposta ao usar o framework OAuth 2.0. Observação: tecnicamente, o OAuth é um framework de autorização delegada, mas é usado extensivamente em padrões de autenticação delegada ou federada.
  • Verificação, decodificação e geração de JSON Web Tokens e JSON Web Signatures do OpenID Connect 1.0
  • Gerar e validar declarações SAML
  • Verificar chaves de API
  • Verificação do código de autenticação de mensagens de hash com chave (HMAC)

Gerenciamento de tráfego

Os seguintes recursos de gerenciamento de tráfego da Apigee ajudam a proteger contra ataques de força bruta:

  • A política Spike Arrest, para definir um limite de taxa de média contínua geral em um proxy de API
  • Políticas de cota para definir limites de taxa refinados em proxies de API com base em cotas definidas por chaves de app, desenvolvedores ou cotas de produtos de API
  • Políticas de armazenamento em cache de tokens de acesso armazenados com base nos tempos de expiração definidos, além da capacidade de invalidar credenciais armazenadas em cache (por exemplo, em uma situação em que um token de acesso válido é comprometido).

Governança

A segurança é um processo contínuo, não um projeto de "configurar e esquecer", e uma das maiores causas de violações de segurança é a configuração incorreta. Depois que os fluxos de autenticação, os padrões de integração de identidade e as políticas de gerenciamento de tráfego relacionadas à autenticação forem definidos, é fundamental que eles sejam implementados de maneira correta e consistente.

A Apigee oferece vários recursos e ferramentas para garantir a integridade da implementação e evitar erros de configuração incorreta.

Controle de acesso baseado em papéis (RBAC)

Seja uma grande empresa ou uma pequena startup, para evitar erros de configuração, é preciso garantir que apenas as pessoas e equipes certas possam acessar e modificar as configurações de proxy de API. Os programas de API são compatíveis com equipes multidisciplinares em toda a organização. É essencial que cada equipe receba apenas as permissões necessárias para realizar o trabalho como parte da jornada da API.

A Apigee oferece recursos para gerenciar o acesso baseado em função, permitindo atribuir usuários a funções predefinidas ou criar funções personalizadas para atender às necessidades das suas equipes de API. Definir e gerenciar corretamente a atribuição de função é fundamental para que você possa escalonar seu programa de API com segurança. Também é possível usar a federação para integrar ao diretório corporativo atual e reduzir a necessidade de gerenciar um segundo conjunto de credenciais de administrador na Apigee.

Fluxos compartilhados

Com os fluxos compartilhados, é possível definir políticas e recursos em um objeto reutilizável que pode ser implementado em proxies de API. Por exemplo, você pode ter projetado em colaboração com suas equipes de segurança vários padrões de design de autenticação com base no tipo de app que consome uma API. Um desenvolvedor de API não precisa ser especialista em identidade para reutilizar isso. Basta saber o fluxo compartilhado correto para adicionar à configuração de proxy de API atual usando a política Callout de fluxo.

Figura: os fluxos compartilhados são pacotes reutilizáveis de políticas e lógica condicional que permitem manter um padrão composto.

Segurança operacional

Depois que as APIs estiverem em produção usando os padrões de autenticação corretos com o gerenciamento de tráfego básico, sua equipe de SecOps também precisará monitorar e responder a atividades suspeitas, que geralmente começam com tentativas de comprometer as credenciais de autenticação.

Apigee Sense

O Apigee Sense protege suas APIs contra tráfego de solicitações indesejadas, incluindo ataques de clientes maliciosos. O Apigee Sense analisa o tráfego de solicitações de API, identificando padrões que podem representar solicitações indesejadas. Com essa análise, é possível identificar clientes que fazem solicitações indesejadas e tomar medidas para permitir, bloquear ou sinalizar essas solicitações. Os recursos futuros do Sense vão incluir a capacidade de ativar automaticamente a verificação do reCAPTCHA em tráfego suspeito.

Com o Apigee Sense, você pode proteger suas APIs contra padrões de solicitação que incluem:

  • Comportamento automatizado que se mistura ao comportamento humano
  • Tentativas persistentes do mesmo IP
  • Taxas de erro incomuns
  • Solicitações suspeitas do cliente
  • Rastreamento de dados
  • Ataques de força bruta para autenticação e coleta de chaves
  • Picos de atividade
  • Padrões geográficos

Operações de APIs avançadas

Embora o Sense tenha sido projetado especificamente para detectar e responder a ameaças semelhantes a bots, o Advanced API Ops inclui detecção de anomalias e definição de alertas avançados.

A detecção de anomalias funciona aplicando modelos de inteligência artificial (IA) e machine learning (ML) aos seus dados históricos de API. A detecção de anomalias pode gerar alertas em tempo real para cenários que você nem imaginou, melhorando sua produtividade e reduzindo o tempo médio de resolução (MTTR) dos problemas da API.

O Advanced API Ops se baseia no mecanismo de alerta da API Monitoring para adicionar os seguintes tipos de alertas avançados:

  • Alertas de anomalia. O Edge detecta problemas de tráfego e desempenho em vez de você ter que pré-determinar esses problemas. Em seguida, você pode gerar um alerta para essas anomalias.
  • Alertas de expiração do TLS. Mostra uma notificação quando um certificado TLS está prestes a expirar

API3:2019 Exposição excessiva de dados

Descrição da ameaça

Uma API publicada pode expor mais dados do que o necessário, dependendo do app cliente para realizar a filtragem necessária. Se um invasor consultar diretamente a API subjacente, ele poderá acessar dados sensíveis.

Um dos princípios de design "de fora para dentro" da Apigee para design de API é a parcimônia de dados. Trabalhe com seus designers de UX e desenvolvedores para expor dados apenas por APIs necessárias na interface do app. Os sistemas de back-end não foram criados para padrões de uso público. Por isso, uma das primeiras tarefas do design com foco na API com o Apigee é reduzir os dados expostos ao mínimo necessário para oferecer um ótimo produto de API aos seus clientes e desenvolvedores.

Outro princípio de design da Apigee é a reutilização. Além das questões de segurança, depender de um app para filtrar os dados fornecidos por uma API resulta na necessidade de portar essa lógica de filtragem para todas as plataformas em que você desenvolve um app.

Do ponto de vista da segurança, essa ameaça resulta da delegação da aplicação da autorização a um app, muitas vezes em uma plataforma ou SO sobre o qual você não tem controle. Já examinamos em API1 e API2 a importância de implementar corretamente a autenticação e a autorização para evitar o acesso não autorizado a dados.

As próximas seções explicam como:

  • Reescrever solicitações e respostas para serviços de back-end para minimizar a exposição de dados
  • Implemente o tratamento de falhas para evitar que mensagens de erro detalhadas exponham informações sensíveis do ambiente a invasores sobre seus serviços de back-end.

Reescrever respostas e solicitações

Normalmente, os sistemas de back-end não são projetados para uso em apps públicos ou em redes públicas não confiáveis. O Apigee Edge foi projetado para permitir que você implante produtos de API pública protegendo seus back-ends contra exposição excessiva de dados.

Para isso, a Apigee usa três políticas principais:

  • Atribuir mensagem
  • Frases de destaque de código
  • Tratamento de falhas

Política de atribuição de mensagens

A política Assign Message muda ou cria novas mensagens de solicitação e resposta durante o fluxo do proxy de API. A política permite realizar as seguintes ações nessas mensagens:

  • Adicionar novos parâmetros de formulário, cabeçalhos ou parâmetros de consulta a uma mensagem
  • Copiar propriedades atuais de uma mensagem para outra
  • Remover cabeçalhos, parâmetros de consulta, parâmetros de formulário e/ou payloads de mensagens
  • Definir o valor das propriedades atuais de uma mensagem

Com a atribuição de mensagem, normalmente é possível adicionar, mudar ou remover propriedades da solicitação ou da resposta. No entanto, também é possível usar a política AssignMessage para criar uma mensagem de solicitação ou resposta personalizada e transmiti-la para um destino alternativo, conforme descrito em Criar mensagens de solicitação personalizadas.

Reescrita complexa com código personalizado

Para manipulação de dados complexa e regras de reescrita que vão além da capacidade da política AssignMessage, use linguagens procedimentais como JavaScript, Java ou Python. É possível adicionar código personalizado a um proxy de API e chamá-lo de políticas adicionadas ao fluxo do proxy. O suporte ao código procedural foi projetado para facilitar a implementação do processamento complexo de variáveis de fluxo, falhas e corpos de solicitação e resposta.

Com o código processual, é possível:

  • Crie ou manipule valores de corpo complexos, como valores de solicitação e resposta.
  • Reescreva os URLs, como mascarar um URL do endpoint de destino.

O Apigee Edge inclui uma política separada para linguagens compatíveis: política de JavaScript, política de callout Java e política de script Python.

Tratamento de falhas

A Apigee permite que você realize o tratamento personalizado de exceções usando uma política do tipo Raise Fault. A política RaiseFault, que é uma variação da política AssignMessage, permite gerar uma resposta de falha personalizada em resposta a uma condição de erro.

Fluxos compartilhados

Os fluxos compartilhados podem ser usados para padronizar as mensagens de falha. Por exemplo, as mesmas políticas configuradas que detectam um código de erro HTTP específico do back-end podem ser usadas para reescrever a resposta de erro e retornar uma mensagem de erro genérica.

API4:2019 Falta de recursos e limitação de taxa

Descrição da ameaça

Ao não implementar políticas de limitação de taxa, os invasores podem sobrecarregar o back-end com ataques de negação de serviço.

Essa ameaça pode ser facilmente resolvida usando os seguintes recursos da Apigee:

  • Políticas de cotas e Spike Arrest como controles preventivos para limitar o tráfego em solicitações de API de entrada
  • Apigee Sense para detectar e responder dinamicamente a ataques baseados em bots
  • Monitoramento e alertas avançados de API como controles de detecção para receber alertas sobre ataques DDoS em andamento

Limitação de taxa com políticas de cotas e Spike Arrest

A Apigee oferece duas políticas para limitação de taxa:

  • O SpikeArrest fornece uma política geral, definida no nível do proxy de API, para limitar a taxa do número geral de solicitações de entrada para um back-end.
  • As cotas oferecem uma ferramenta de política granular para aplicar políticas de cota, seja em um proxy de API ou em um produto de API.

Spike Arrest

A política Spike Arrest protege contra picos de tráfego. Essa política limita o número de solicitações processadas por um proxy de API e enviadas para um back-end, protegendo contra atrasos de desempenho e inatividade, usando um valor de média contínua definível na política.

Cotas

A política de Quota permite configurar o número de mensagens de solicitação que um proxy de API permite durante um período, como um minuto, uma hora, um dia, uma semana ou um mês. É possível definir a cota como a mesma para todos os apps que acessam o proxy de API ou definir a cota com base em:

  • O produto que contém o proxy da API
  • O app que solicita a API
  • O desenvolvedor do app
  • Vários outros critérios

Essa política é mais granular do que a SpikeArrest e geralmente deve ser usada simultaneamente com ela.

Detecção de bots com o Apigee Sense

Com o Apigee Sense, é possível permitir, bloquear ou sinalizar explicitamente solicitações de clientes, intervalos de IP ou organizações de sistemas autônomos específicos com base em clientes ou locais que apresentem comportamento malicioso ou suspeito. O Apigee Edge aplica essas ações às solicitações antes que os proxies de API as processem. Por exemplo, um intervalo de IP ou um cliente específico que exibe comportamento de "brute guessor" pode ser detectado, bloqueado ou sinalizado.

Detecção de ameaças com o Advanced API Ops Monitoring

Use um alerta de tráfego para gerar uma notificação quando o tráfego de um ambiente, proxy ou região mudar em uma porcentagem especificada em um período. Esse recurso pode gerar um alerta dinamicamente quando o tráfego se desvia significativamente do seu throughput esperado, como em um ataque DDoS. Esses alertas podem ser enviados facilmente para uma solução de geração de registros e monitoramento de terceiros.

API5:2019 Autorização de nível de função corrompida

Descrição da ameaça

Essa ameaça é uma variação da API1 e também é uma vulnerabilidade de autorização. Com essa ameaça, um invasor pode realizar ações enviando solicitações para funções a que não tem autorização de acesso. Por exemplo, um invasor pode modificar ou excluir dados que só tem autorização para ler se um endpoint de API não validar o verbo de solicitação HTTP, substituindo um GET por um PUT ou DELETE. Ou, ao não implementar um controle de acesso suficientemente restritivo em um caminho de URI de recurso de API, um endpoint de API pode permitir que um invasor veja os dados de outro usuário simplesmente mudando o caminho em uma solicitação.

Esse tipo de ameaça destaca o valor de usar a Apigee como uma camada de mediação e abstração, já que muitos sistemas de back-end, que não foram projetados para acesso público, podem fornecer por padrão um único endpoint para executar várias funções de lógica de negócios, incluindo funcionalidades administrativas de alto risco.

Os elementos conceituais para reduzir a probabilidade dessa ameaça geralmente são divididos em:

  • O que está sendo protegido? Pense na sua estratégia de produtos de API e implemente uma segmentação lógica de funcionalidades ao usar práticas recomendadas RESTful para projetar os caminhos e recursos expostos por proxies, produtos e recursos de apps da API Apigee.
  • Quem está acessando seus recursos de API? Defina as personas de alto nível e implemente direitos de acesso padrão de "privilégio mínimo" usando alguns dos recursos de autenticação e autorização da Apigee, conforme descrito em API1 e API2.
  • Como as políticas de acesso são aplicadas? Use fluxos e falhas condicionais para validar o caminho do URL e o verbo de todas as solicitações de API.

Figura: este diagrama demonstra como a autorização no nível da função seria aplicada na Apigee, usando escopos fornecidos em um token de acesso como direitos.

Segmentação lógica com proxies, produtos e apps de API

A Apigee oferece um kit de ferramentas altamente flexível para permitir a segmentação lógica de recursos de API, permitindo que proxies de API sejam agrupados em qualquer número de produtos de API, que, por sua vez, são consumidos pelos desenvolvedores de apps, que podem registrar apps que usam seus produtos de API. As políticas de acesso podem ser definidas em qualquer um desses níveis.

No entanto, para implementar uma autorização e segmentação funcionais eficazes, é fundamental definir uma estratégia de produtos de API. Parte desse processo essencial e contínuo é a definição do "quem" e do "o quê" dos seus produtos de API, analisando os recursos de API na perspectiva do cliente e do desenvolvedor e, em seguida, definindo até um recurso de caminho e um nível de verbo HTTP, exatamente quais tipos de solicitações serão permitidos.

Figura: os recursos de API agrupados em um produto de API podem vir de uma ou mais APIs. Assim, é possível combinar recursos para criar níveis de consumo e limites de autorização.

Controle de acesso no nível da função com escopos do OAuth e declarações JWT

Embora as abordagens de autorização consideradas acima para API1:2019 Autorização de objeto corrompida abordem o controle de acesso refinado no nível do objeto, é igualmente importante abordar o controle de acesso granular no nível da função. O usuário solicitante tem permissão para pedir esse caminho do URL? Esse tipo de política geralmente é definido por persona do usuário (cliente, funcionário, administrador, desenvolvedor interno ou terceirizado).

Para reduzir o risco de configuração incorreta, recomendamos trabalhar com sua equipe de segurança para garantir que as declarações sobre o usuário solicitante estejam contidas no token de acesso, usando escopos do OAuth ou declarações JWT.

Validação de solicitações com fluxos condicionais

Em um nível fundamental, uma chamada de API REST é composta do seguinte:

  • Um endpoint
  • um recurso
  • Um verbo de ação
  • Qualquer número de atributos de solicitação adicionais, como parâmetros de consulta

O tipo de ataque descrito nessa ameaça geralmente é causado pela filtragem insuficiente de uma solicitação de API, permitindo que um invasor execute ações não autorizadas ou acesse um recurso protegido. Além da lógica condicional, que permite filtrar solicitações com base em tokens de acesso ou declarações, a Apigee permite a implementação de uma lógica de filtragem com base na própria solicitação.

Depois de entender e definir claramente a lógica de negócios de um produto de API e as funções permitidas pelas APIs, a próxima etapa é restringir as solicitações que não se enquadram nisso usando estes recursos do produto Apigee:

  • Lógica condicional e políticas RaiseFault para restringir caminhos ou verbos de recursos em qualquer etapa de uma configuração de fluxo de proxy
  • Políticas de proteção contra ameaças JSON e XML para proteger contra ataques baseados em conteúdo usando payloads de solicitação JSON ou XML malformados

API6:2019 Atribuição em massa

Descrição da ameaça

Os dados não filtrados fornecidos por APIs a apps clientes permitem que invasores adivinhem propriedades de objetos por solicitações ou usem convenções de nomenclatura de endpoints para encontrar pistas de onde realizar modificações ou acessos não autorizados de propriedades em objetos de dados armazenados no back-end.

Essa ameaça ocorre quando dados não filtrados (normalmente em JSON ou XML) são enviados a um cliente, permitindo que um invasor adivinhe os detalhes de implementação dos sistemas de back-end, bem como os nomes de propriedades de elementos de dados confidenciais. O resultado desse tipo de ataque pode conceder a um invasor a capacidade de ler ou manipular dados inadequados ou, na pior das hipóteses, ativar vulnerabilidades de execução remota de código.

Normalmente, há dois aspectos envolvidos que permitem esse tipo de ameaça:

  • A perspectiva do design de API. Nunca confie na lógica do aplicativo para realizar a filtragem de dados do lado do cliente, já que os apps podem ser explorados por invasores e considerados confiáveis. Sempre crie seu esquema de dados da API para expor apenas os dados mínimos e necessários para ativar um serviço de API.
  • A perspectiva de implementação da API. Implemente a filtragem de dados e a validação de esquema para evitar a exposição inadvertida de dados confidenciais a um aplicativo cliente.

Do ponto de vista do produto Apigee, oferecemos vários recursos úteis para garantir uma implementação robusta de filtragem de dados das suas APIs.

Política de filtragem de especificação OpenAPI

A política OASValidation (Validação da especificação OpenAPI) permite validar uma solicitação ou mensagem de resposta recebida em relação a uma especificação OpenAPI 3.0 (JSON ou YAML). Com essa política, você pode:

  1. Projete sua API criando uma especificação OpenAPI (OAS)
  2. Implemente a mediação, a segurança e a lógica de armazenamento em cache necessárias para expor com segurança um produto de API do seu back-end com a Apigee.
  3. Validar solicitações recebidas em relação ao esquema de dados definido na especificação OAS, incluindo basepath, verbo, política de mensagem de solicitação e parâmetros.

Política de validação de mensagens SOAP

A política de validação de mensagens SOAP permite validar solicitações baseadas em XML, seja validando uma mensagem XML em relação a um esquema XSD ou uma mensagem SOAP em relação a uma definição WSDL. Além disso, você pode usar a política de validação de mensagens para confirmar se um payload de mensagem JSON ou XML está bem formado, o que inclui verificar o seguinte em uma mensagem XML ou JSON:

  • Há um único elemento raiz
  • Não há caracteres inválidos no conteúdo
  • Objetos e tags estão aninhados corretamente
  • As tags de início e de término coincidem

API7:2019 Configuração incorreta de segurança

Descrição da ameaça

Configurações incorretas geralmente ocorrem devido a configurações padrão inseguras, configurações incompletas ou ad hoc, armazenamento em nuvem aberta, cabeçalhos HTTP mal configurados, métodos HTTP desnecessários, compartilhamento de recursos de origem cruzada (CORS) permissivo e mensagens de erro detalhadas com informações sensíveis. Os invasores geralmente tentam encontrar falhas sem patch, endpoints comuns ou arquivos e diretórios desprotegidos para conseguir acesso não autorizado ou conhecimento do sistema que querem atacar. As configurações incorretas de segurança podem expor dados sensíveis do usuário e detalhes do sistema que podem levar ao comprometimento total do servidor. Além disso, alguns outros casos de uso para vulnerabilidades de configurações incorretas de segurança podem incluir:

  • TLS mal configurado
  • Mensagens de erro com stack traces
  • Sistemas sem patch
  • Painéis de gerenciamento de armazenamento ou servidor expostos

As organizações podem tomar várias medidas para resolver e reduzir os desafios relacionados a configurações incorretas de segurança, incluindo:

  1. Estabelecer e padronizar processos de proteção e correção
  2. Desenvolver governança no ecossistema de APIs
  3. Restringir o acesso administrativo e ativar a auditoria e os alertas

Fluxos compartilhados e ganchos de fluxo

A Apigee oferece suporte ao conceito de fluxo compartilhado, que permite que os desenvolvedores de API combinem políticas e recursos em um grupo reutilizável. Ao capturar funcionalidades reutilizáveis em um lugar, um fluxo compartilhado ajuda a garantir consistência, diminuir o tempo de desenvolvimento e gerenciar o código com mais facilidade. É possível incluir um fluxo compartilhado em proxies de API individuais ou ir além e colocar fluxos compartilhados em ganchos de fluxo para executar automaticamente a lógica de fluxo compartilhado para cada proxy de API implantado no mesmo ambiente que um fluxo compartilhado.

Monitoramento de APIs

A Apigee oferece uma plataforma abrangente de monitoramento de APIs. Com o Monitoramento de APIs, as organizações podem detectar de forma proativa problemas de tráfego e desempenho de API. O Monitoramento de APIs do Apigee funciona com o Apigee Edge para nuvem pública e fornece insights contextuais em tempo real sobre o desempenho da API, ajuda a diagnosticar problemas rapidamente e facilita ações corretivas para a continuidade dos negócios.

Figura: o monitoramento de APIs da Apigee oferece uma ampla variedade de ferramentas para monitorar, investigar e resolver problemas. Ele aproveita os melhores recursos de inteligência do Google Cloud Platform.

Apigee Sense

O Apigee Sense ajuda a proteger as APIs contra tráfego de solicitações indesejadas, incluindo ataques de clientes mal-intencionados. O Apigee Sense analisa o tráfego de solicitações de API, identificando padrões que podem representar solicitações indesejadas.

Com essa análise, as organizações podem identificar clientes que fazem solicitações indesejadas e tomar medidas para permitir, bloquear ou sinalizar essas solicitações. Com o Apigee Sense, é possível proteger as APIs contra padrões de solicitação que incluem:

  • Comportamento automatizado que se mistura ao comportamento humano
  • Tentativas persistentes do mesmo IP
  • Taxas de erro incomuns
  • Solicitações suspeitas do cliente
  • Rastreamento de dados
  • Coleta de chaves
  • Picos de atividade
  • Padrões geográficos

API8:2019 Injection

Descrição da ameaça

A injeção não confiável de dados, como SQL, NoSQL, analisadores XML, ORM, LDAP, comandos do SO e JavaScript, em solicitações de API pode resultar na execução de comandos não intencionais ou acesso aos dados não autorizado. Os invasores vão alimentar a API com dados maliciosos usando os vetores de injeção disponíveis, como entrada direta, parâmetros, serviços integrados etc., esperando que ela seja enviada a um intérprete. Os invasores podem descobrir essas falhas facilmente ao analisar o código-fonte usando verificadores de vulnerabilidade e fuzzers. Uma injeção bem-sucedida pode levar à divulgação de informações afetando a confidencialidade e a perda de dados ou, em alguns casos, também pode levar a DoS.

As práticas recomendadas para reduzir erros/ataques de injeção incluem definir estritamente os dados de entrada, como esquemas, tipos e padrões de string, realizar validação de entrada, verificações de limite e aplicá-los em tempo de execução. A plataforma Apigee permite validar os dados recebidos usando filtros para permitir apenas valores válidos para cada parâmetro de entrada.

O Apigee Edge, atuando como um servidor para as solicitações de API recebidas, verifica se a estrutura de payload está dentro de um intervalo aceitável, também conhecido como verificação de limite. É possível configurar um proxy de API para que a rotina de validação de entrada transforme a entrada, removendo sequências de caracteres arriscadas e substituindo-as por valores seguros.

Política de proteção de expressões regulares

A política RegularExpressionProtection extrai informações de uma mensagem (por exemplo, caminho de URI, parâmetro de consulta, cabeçalho, parâmetro de formulário, variável, payload XML ou payload JSON) e avalia esse conteúdo em expressões regulares predefinidas. Se alguma expressão regular especificada for avaliada como verdadeira, a mensagem será considerada uma ameaça e será rejeitada. Uma expressão regular, ou regex, é um conjunto de strings que especificam um padrão em uma string. As expressões regulares permitem que o conteúdo seja avaliado de maneira programática para os padrões. As expressões regulares podem ser usadas, por exemplo, para avaliar um endereço de e-mail e garantir que ele esteja estruturado de forma adequada.

O uso mais comum de RegularExpressionProtection é a avaliação de payloads JSON e XML em busca de conteúdo malicioso.

Nenhuma expressão regular pode eliminar todos os ataques baseados em conteúdo, e vários mecanismos precisam ser combinados para ativar a defesa em profundidade. Esta seção descreve alguns padrões recomendados para impedir o acesso ao conteúdo.

Há várias outras abordagens para validar entradas disponíveis na plataforma Apigee:

Validar tipos de conteúdo

O tipo de conteúdo se refere ao conteúdo de um arquivo transferido por HTTP e classificado de acordo com uma estrutura de duas partes. A Apigee recomenda validar os tipos de conteúdo da solicitação e da resposta usando a lógica condicional, conforme explicado abaixo.

API9:2019 Gerenciamento inadequado de recursos

Descrição da ameaça

O gerenciamento e a segregação insuficientes do ambiente permitem que os invasores acessem endpoints de API pouco protegidos. A falta de salvaguardas de governança também causa a exposição desnecessária de recursos descontinuados.

Essa ameaça pode ser abordada aproveitando os recursos avançados da Apigee para gerenciar todo o ciclo de vida da API, permitindo que você crie um modelo de governança abrangente que possibilite a colaboração entre equipes e, ao mesmo tempo, aplique a separação de responsabilidades entre os stakeholders de segurança e os desenvolvedores de API. É possível configurar e manter limites e controles usando:

Organizações, ambientes e revisões: proteções virtuais e físicas que garantem o isolamento e um processo de promoção seguro por contextos de execução.

Controle de acesso baseado em função: apenas as pessoas necessárias nas equipes de API terão permissões para gerenciar mudanças de configuração e o processo de promoção.

Gerenciamento de público-alvo para documentação da API: depois que uma API é publicada no portal de desenvolvedores, é possível limitar a visibilidade da documentação gerenciando os públicos-alvo.

Hooks de fluxo: é possível aplicar políticas e padrões globais que podem ser gerenciados como proteções privilegiadas que não podem ser modificadas por desenvolvedores de API.

Organizações e ambientes

Os artefatos de configuração, os usuários e os recursos da Apigee podem ser definidos para organizações e/ou ambientes específicos. Isso significa que a plataforma tem proteções pré-criadas que podem ser colocadas em torno das APIs e da configuração de suporte delas.

Organizações: Uma organização é o locatário de nível superior na Apigee. Isso permite uma segregação completa de tráfego, configuração e usuários. Como prática recomendada de governança, considere ter organizações de produção e não produção separadas. Essa prática evita efetivamente a mistura de dados, usuários e tráfego de produção com ambientes inferiores.

Ambientes: as APIs no Apigee podem ser promovidas em vários estados de implantação. Cada estado está vinculado a um contexto de execução. O contexto do ambiente não é transferido durante o processo de promoção, evitando assim a exposição de configurações sensíveis a usuários sem privilégios.

Revisões: As revisões permitem que APIs e recursos individuais sejam promovidos sem problemas em todos os ambientes.

Controle de acesso baseado em papéis

Para mitigar API9, é fundamental ter definições claras e segregação de funções entre as partes interessadas em segurança e os desenvolvedores de API. Conforme declarado anteriormente neste documento, a Apigee tem recursos flexíveis de controle de acesso baseado em função que permitem atribuir permissões a papéis personalizados. Para essa ameaça específica, as funções podem ter escopo limitado por organização, ambientes ou permissões de configuração mais granulares. Como prática recomendada, limite os privilégios para mudar o estado de implantação das APIs em ambientes e para garantir que os desenvolvedores não possam acessar ou modificar bibliotecas de segurança globais (hooks de fluxo). Essas funções limitadas impedem mudanças não solicitadas nas políticas de segurança globais, que têm ampla cobertura em endpoints legados e publicados atualmente.

Gerenciamento de públicos-alvo para documentação da API

Um portal do desenvolvedor é um componente fundamental para o sucesso da sua estratégia de API. Ele permite manter um inventário abrangente de toda a documentação relacionada às suas APIs, incluindo hosts/endpoints, recursos, operações, esquemas de payload e muito mais. Na Apigee, é possível agrupar suas APIs usando construções de produtos de API. Os produtos de API são definidos por pacotes de recursos e operações que se enquadram no mesmo contexto comercial e de segurança (por exemplo, plano de serviço, domínio comercial, categoria, hierarquia da empresa etc.).

Com o portal de desenvolvedores integrado do Apigee, é possível publicar produtos de API e restringir a visibilidade do conteúdo publicado gerenciando públicos-alvo. Essa capacidade está em conformidade com uma estratégia de segmentação de conteúdo que se alinha aos requisitos comerciais e de segurança.

Ganchos de fluxo

Os processos de promoção e lançamento de APIs precisam sempre incluir processos de certificação e conformidade de segurança. Para serem eficazes, as equipes de API que usam as ferramentas adequadas precisam criar proteções que garantam a separação de responsabilidades e mantenham ciclos de lançamento ágeis.

A Apigee permite elevar as responsabilidades de governança de segurança aplicando políticas globais com os hooks de fluxo. Essas políticas globais podem ser gerenciadas como barreiras privilegiadas que não podem ser modificadas por desenvolvedores de API. Assim, garantem a separação de responsabilidades e promovem a agilidade ao aplicar a segurança padrão e, por extensão, fornecer conformidade de segurança para todas as APIs implantadas em um determinado ambiente de execução.

Figura: os guardrails privilegiados podem ser configurados no Apigee usando hooks de fluxo e fluxos compartilhados. As partes interessadas em segurança são responsáveis por manter as políticas globais relacionadas à segurança. Esses recursos garantem a separação de responsabilidades e promovem ciclos de vida de desenvolvimento ágil.

API10:2019 Geração de registros e monitoramento insuficientes

Descrição da ameaça

O registro, o monitoramento e os alertas insuficientes permitem que ataques em andamento passem despercebidos. Portanto, é necessário ter uma estratégia para obter insights sobre eventos críticos que afetam sua empresa.

As estratégias de gerenciamento de eventos e registros para APIs precisam considerar as seguintes práticas recomendadas:

  • Política de gerenciamento de registros: documente e aplique regras para padronizar e controlar a verbosidade, os níveis e a integridade dos registros, o repositório centralizado e muito mais.
  • Política de gerenciamento de eventos: garante que todos os eventos sejam rastreáveis até a origem. Além disso, os eventos precisam ser categorizados por gravidade e impacto nos negócios.
  • Relatórios e auditorias: as partes interessadas em segurança e operações precisam acessar e reagir a registros e eventos em tempo real. Além disso, as partes interessadas podem realizar ciclos de reforço para ajustar os padrões de detecção com base em dados históricos.

A Apigee oferece as ferramentas necessárias para criar uma estratégia abrangente de gerenciamento de eventos e registros. Essas ferramentas incluem:

Política de registro de mensagens: crie fluxos de registros com base em informações de trânsito ou metadados do tráfego da sua API. Você tem a flexibilidade de decidir a verbosidade do stream usando a lógica condicional e modelos de mensagens.

Pacote de operações na nuvem do Google: aproveite a integração pronta para uso em ferramentas de monitoramento e geração de registros altamente escalonáveis do Google.

Política de destaque do serviço: adiciona suporte para fluxos de registros que exigem endpoints HTTP para enviar eventos.

Analytics: Acesse e analise metadados históricos de tráfego usando relatórios prontos para uso e/ou personalizados. Crie e gerencie alertas com base em tendências e entenda as anomalias de tráfego.

Monitoramento de API: como descrito anteriormente, essa ferramenta oferece recursos de alerta que podem ser acionados com base em eventos críticos. Os registros de tráfego podem ser analisados e usados para ações.