10 principais ameaças à API do OWASP

Você está visualizando 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 pelo OWASP. Para outras abordagens documentadas para o Apigee, consulte As 10 principais opções de mitigação da OWASP para 2021 no Google Cloud.

Introdução

O OWASP (link em inglês) é uma comunidade aberta dedicada a ajudar organizações a desenvolver, comprar e manter aplicativos e APIs confiáveis. No 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 e oferece recomendações para lidar com esses riscos.

Este documento discute abordagens para se proteger contra ataques comuns baseados em API, conforme identificado pelas dez principais ameaças de segurança de API da OWASP em 2019. Um tema comum nas principais ameaças destacadas pela lista mais recente é causado pela colocação inadequada 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 executar a aplicação do controle de acesso.

Com o crescimento do ecossistema de APIs acontecendo a uma velocidade incrível, os abusos e usos indevidos de APIs 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 importante para a Apigee, com vários novos recursos, como Operações avançadas de API, que inclui recursos de relatórios de segurança e detecção de anomalias. No entanto, projetar e implementar os recursos de segurança do Apigee corretamente é fundamental para reduzir a probabilidade de ataques bem-sucedidos às suas APIs.

Os aplicativos do consumidor precisam 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 possa e será comprometido. 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 dos 10 principais ataques da OWASP de 2019:

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

API1:2019 Autorização de objeto inválida

Descrição da ameaça

A validação de autorização insuficiente 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 de validações de autorização. A Apigee fornece 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 de segurança colaborem de perto. A autorização é, por natureza, um tópico complexo, e a autorização detalhada eficaz requer um entendimento profundo da lógica de negócios do aplicativo.

Há dois aspectos principais a serem considerados na 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 OAuth ou OpenID Connect correto com o mecanismo de validação ou assinatura de credenciais adequado. A Apigee oferece suporte a todos os fluxos do OAuth mais usados.

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

Aplicação do controle de acesso

Depois que a validade do token de acesso for verificada, é fundamental implementar políticas de aplicação 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: usar 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.
  • Delegada: usar um chamado 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 as 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 reivindicações extraídas de um token de acesso não podem ser usadas diretamente para autorizar uma solicitação de API para um objeto de back-end ou para tipos de fluxo OAuth mais complexos que exigem uma chamada separada para um servidor de autorização para receber um token de acesso.

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

API2:2019 Autenticação de usuário com falha

Descrição da ameaça

Políticas de autenticação de usuário mal implementadas permitem que invasores falsifiquem a identidade de usuários legítimos aproveitando as falhas de implementação nas implementações de autenticação. Alguns princípios de autenticação que devem ser considerados ao implementar abordagens de autenticação incluem:

  • Sempre autenticar o user agent (o app) e o usuário solicitante
  • Use padrões de autenticação e autorização delegados 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 de acesso usadas têm um prazo de validade definido.
  • Evite ataques de força bruta definindo cotas e usando o Apigee Sense para detectar e responder a ataques de força bruta dirigidos por bots.

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

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

  • Design de segurança: use todos os recursos da Apigee para implementar padrões de autenticação.
  • Governança: garantir que os padrões de autenticação projetados sejam usados de forma consistente em todos os produtos de API publicados
  • Segurança operacional: capacidade de detectar comportamentos suspeitos ou anormais e tentativas de contornar ou forçar proxies de API autenticados

Design de segurança

O objetivo do design de segurança é implementar corretamente os fluxos de autenticação e a integração com ferramentas de identidade de terceiros. O design de segurança é uma fase crítica e 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 os endpoints da API. A próxima etapa é definir, junto com a equipe de identidade, os padrões de integração a serem implementados com a solução de identidade.

Os RFCs do OpenID Connect e do OAuth fornecem um grande número de fluxos de autenticação e autorização delegados, além de atores envolvidos nesses fluxos. Esse é um tópico complexo, e não é surpresa que a autenticação quebrada seja uma das principais ameaças de API da OWASP. Fornecer uma introdução abrangente sobre a implementação correta dos padrões de identidade está fora do escopo deste documento, mas a Apigee tem muitos outros recursos 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:

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 média geral em um proxy de API
  • Políticas de cotas, para definir limites de taxa detalhados em proxies de API com base em cotas definidas por chaves de apps, desenvolvedores ou cotas de produtos de API.
  • Políticas de armazenamento em cache para armazenamento em cache de tokens de acesso com base nos tempos de expiração definidos, além da capacidade de invalidate 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 principais 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.

Controle de acesso baseado em papéis (RBAC)

Seja uma grande empresa ou uma pequena startup, evite erros de configuração garantindo que apenas as pessoas e equipes certas possam acessar e modificar as configurações do proxy de API. Os programas de API têm suporte de 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 você gerenciar o acesso baseado em função, fornecendo os recursos para atribuir usuários a papéis predefinidos ou criar papéis personalizados para atender às suas equipes de API. Definir e gerenciar corretamente a atribuição de papéis é fundamental para que você possa dimensionar seu programa de API com segurança. Você também pode usar a federação para integrar com seu diretório corporativo e reduzir a necessidade de gerenciar um segundo conjunto de credenciais de administrador na Apigee.

Fluxos compartilhados

Os fluxos compartilhados permitem definir políticas e recursos em um objeto reutilizável que pode ser implementado em vários 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 um especialista em identidade para reutilizar isso. Ele só precisa saber o fluxo compartilhado correto para adicionar à configuração de proxy de API usando a política de chamada 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.

Relatórios de segurança

Depois de garantir que apenas as pessoas certas na sua organização possam modificar os padrões de autenticação e definir os fluxos de autenticação compartilhados, é necessário garantir que os proxies de API desenvolvidos pelas equipes de API estejam usando esses padrões de autenticação de forma consistente.

O novo recurso Operações avançadas de API do Apigee inclui relatórios de segurança avançados, que permite que as equipes de operações e segurança acessem facilmente relatórios sobre todos os proxies de API e se concentra na adesão a políticas de segurança, como o uso de fluxos compartilhados. Relatórios, registros e alertas são um elemento-chave da segurança da API, que será discutido em mais detalhes em API10: registro insuficiente, mas, do ponto de vista de prevenção de riscos de autenticação quebrada, é extremamente útil para garantir a adesão aos padrões de autenticação definidos implementados como fluxos compartilhados.

Segurança operacional

Depois que as APIs estiverem em produção usando os padrões de autenticação certos com o gerenciamento de tráfego de referência em vigor, a 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 indesejado, incluindo ataques de clientes mal-intencionados. O Apigee Sense analisa o tráfego de solicitações da API, identificando padrões que podem representar solicitações indesejadas. Usando essa análise, você pode identificar clientes que fazem solicitações indesejadas e, em seguida, 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 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
  • Coleta de chaves e ataques de força bruta de autenticação
  • Picos de atividades
  • Padrões geográficos

Operações de APIs avançadas

O Sense foi projetado especificamente para detectar e responder a ameaças semelhantes a bots. O Advanced API Ops inclui a detecção de anomalias e a definição de alerta avançado.

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

As Operações avançadas de API são baseadas no mecanismo de alerta da API Monitoring para adicionar os seguintes tipos de alerta avançados:

  • Alertas de tráfego total. Gera um alerta quando o tráfego muda em uma porcentagem especificada ao longo de um período. Por exemplo, é possível gerar um alerta quando o tráfego aumentar 5% ou mais por uma hora ou diminuir 10% ou mais por uma semana.
  • Alertas de anomalia. O Edge detecta problemas de tráfego e desempenho em vez de você precisar predeterminá-los por conta própria. Em seguida, você pode gerar um alerta para essas anomalias.
  • Alertas de expiração de TLS. Gera uma notificação quando um certificado TLS está prestes a expirar

API3:2019 Excessiva exposição 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, ele poderá acessar dados sensíveis.

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

Outro princípio de design da Apigee é a reutilização. Além das preocupações de segurança, confiar em um app para filtrar os dados fornecidos por uma API resulta na necessidade de transferir 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 de autorização a um app, geralmente em uma plataforma ou SO sobre a qual você não tem controle. Já examinamos na API1 e na 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 examinam como:

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

Como reescrever respostas e solicitações

Os sistemas de back-end geralmente 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 a exposição excessiva de dados.

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

  • Atribuir mensagem
  • Frases de destaque do código
  • Como lidar com falhas

Política de atribuição de mensagens

A política Atribuir mensagem muda ou cria novas mensagens de solicitação e resposta durante o fluxo de proxy da 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 de uma mensagem
  • Definir o valor das propriedades atuais de uma mensagem

Com a função "Atribuir mensagem", você normalmente adiciona, altera ou remove propriedades da solicitação ou da resposta. No entanto, também é possível usar a opção "Atribuir mensagem" para criar uma mensagem de resposta ou solicitação personalizada e transmiti-la para um destino alternativo, conforme descrito em Criar mensagens de solicitação personalizadas.

Reescrita complexa com código personalizado

Para regras de processamento e reescrita de dados complexas que estão além da capacidade da política de atribuição de mensagens, use linguagens procedurais, como JavaScript, Java ou Python. Você pode adicionar um código personalizado a um proxy da API e, em seguida, chamá-lo de políticas adicionadas ao fluxo do proxy. O suporte a códigos procedurais é projetado para facilitar a implementação do tratamento 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 as linguagens com suporte: política JavaScript, política de chamada Java e política de script Python.

Gerenciamento 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 "Gerar falha", que é uma variação da política "Atribuir mensagem", 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 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 para 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 do Apigee:

  • Políticas de cotas e de detenção de pico como controles preventivos para limitar o tráfego de solicitações de API de entrada
  • Apigee Sense para detectar e responder dinamicamente a ataques de 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 detenção de pico

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

  • A detenção de pico fornece uma política geral, definida no nível do proxy da API, para limitar a taxa do número total de solicitações recebidas em um back-end.
  • As cotas oferecem uma ferramenta de política granular para aplicar políticas de cota em um nível de proxy ou de produto de API.

Spike Arrest

A política de Detenção de pico protege contra o aumento do tráfego. Essa política limita o número de solicitações processadas por um proxy de API e enviadas a um back-end, protegendo contra atrasos de desempenho e inatividade, usando um valor médio móvel definível na política.

Cotas

A política de cota permite a configuração do 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 da 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 detalhada do que a Spike Arrest e geralmente precisa ser usada com ela.

Detecção de bots com o Apigee Sense

Com o Apigee Sense, é possível tomar medidas para permitir, bloquear ou sinalizar explicitamente solicitações de clientes, intervalos de IP ou organizações de sistema autônomo específicos com base em clientes ou locais que apresentam 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 apresente comportamento de "tentativa de adivinhação bruta" pode ser detectado e, em seguida, bloqueado ou sinalizado.

Detecção de ameaças com o monitoramento avançado de operações de API

Use um alerta de tráfego para gerar uma notificação quando o tráfego de um ambiente, proxy ou região mudar por uma porcentagem especificada ao longo de um período. Esse recurso pode gerar um alerta dinâmico quando o tráfego se desvia significativamente da taxa de transferência esperada, como seria o caso durante um ataque DDoS. Esses alertas podem ser enviados facilmente para uma solução de monitoramento e geração de registros 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 que não têm autorização para acessar. Por exemplo, um invasor pode modificar ou excluir dados que só podem ser lidos 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 da API, um endpoint da API pode permitir que um invasor acesse 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 até mesmo funções 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 estratégia do produto da API e implemente a segmentação lógica da funcionalidade ao usar as práticas recomendadas RESTful para projetar os caminhos e recursos expostos pelos proxies de API, produtos e recursos de apps da Apigee.
  • Quem está acessando seus recursos de API? Defina as personas de alto nível e implemente os direitos de acesso padrão de "privilégio mínimo" usando alguns dos recursos de autenticação e autorização do Apigee, conforme descrito na API1 e na API2.
  • Como suas políticas de acesso estão sendo 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 os 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 dos recursos de API, permitindo que os 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 a autorização e segmentação funcional eficaz, é essencial definir uma estratégia de produto de API. Parte desse processo essencial e contínuo é a definição de "quem" e "o que" dos seus produtos de API, analisando os recursos da API pela perspectiva do cliente e do desenvolvedor e, em seguida, definindo 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, você pode misturar e 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 inválida abordem o controle de acesso refinado no nível do objeto, é igualmente importante abordar o controle de acesso grosseiro no nível da função. O usuário solicitante tem permissão para solicitar esse caminho de URL? Esse tipo de política geralmente é definido por perfil de usuário (cliente, funcionário, administrador, desenvolvedor interno ou de terceiros).

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

Solicitar validação com fluxos condicionais

Em um nível básico, uma chamada de API REST é composta por:

  • 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 nesta ameaça normalmente é causado pela filtragem insuficiente de uma solicitação de API, permitindo que um invasor realize 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 da 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, quais funções são permitidas pelas suas APIs, a próxima etapa é restringir as solicitações que não se enquadram nessa categoria usando estes recursos do produto da Apigee:

  • Políticas de lógica condicional e Raise Fault para restringir caminhos de recursos ou verbos em qualquer etapa da configuração de um fluxo de proxy
  • Políticas de JSON XML e XML para se 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 os invasores adivinhem as propriedades do objeto por meio de solicitações ou usem convenções de nomenclatura de endpoints para ter pistas sobre onde realizar a modificação não autorizada ou o acesso a propriedades em objetos de dados armazenados no back-end.

Essa ameaça é causada 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 subjacentes dos sistemas de back-end, bem como os nomes de propriedade de elementos de dados confidenciais. O resultado desse tipo de ataque pode permitir que um invasor leia ou manipule dados inadequados ou, na pior das hipóteses, permitir vulnerabilidades de execução remota de código.

Há dois aspectos que normalmente permitem esse tipo de ameaça:

  • A perspectiva do design da API. Nunca confie na lógica do aplicativo para realizar a filtragem de dados do lado do cliente, porque os apps podem ser explorados por invasores e considerados confiáveis. Sempre projete o 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. Implementar o filtro de dados e a validação de esquema para evitar a exposição involuntária de dados confidenciais a um aplicativo cliente

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

Política de filtragem da especificação OpenAPI

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

  1. Projetar sua API criando uma especificação OpenAPI (OAS)
  2. Implemente a lógica de mediação, segurança e armazenamento em cache necessária para expor com segurança um produto de API do seu back-end com a Apigee.
  3. Valida as solicitações recebidas em relação ao esquema de dados definido na especificação OAS, incluindo o caminho base, o verbo, a política de mensagem de solicitação e os 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, validando uma mensagem XML em um esquema XSD ou uma mensagem SOAP em uma definição WSDL. Além disso, você pode usar a política de validação de mensagens para confirmar se o payload de uma mensagem JSON ou XML está bem formado, o que inclui a verificação do 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 entre origens (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 eles querem atacar. As configurações incorretas de segurança podem expor dados sensíveis do usuário, além de detalhes do sistema que podem comprometer o servidor. Além disso, alguns outros casos de uso de vulnerabilidades para configurações de segurança incorretas podem incluir:

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

Há várias etapas que as organizações podem seguir 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 de vulnerabilidades
  2. Como desenvolver a governança do ecossistema de API
  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 só lugar, um fluxo compartilhado ajuda a garantir a consistência, reduzir 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.

Relatórios de segurança da API

À medida que as organizações se esforçam para desenvolver um framework de governança, a Apigee oferece recursos relacionados a relatórios de segurança da API, que ajudam as equipes operacionais a ter a visibilidade necessária dos atributos de segurança das APIs para:

  • Garantir a adesão às políticas de segurança e aos requisitos de configuração
  • Proteger dados sensíveis contra abuso interno e externo
  • Identificar, diagnosticar e resolver incidentes de segurança de forma proativa

Os relatórios de segurança do Apigee fornecem insights detalhados para as equipes de operações garantirem a adesão a políticas e requisitos de configuração, proteger APIs contra abuso interno e externo e identificar e resolver incidentes de segurança rapidamente.

Com os relatórios de segurança, os administradores de segurança podem entender rapidamente como os proxies da API são configurados para segurança, além das condições de execução que podem afetar a segurança do proxy. Usando essas informações, você pode ajustar a configuração para garantir o nível adequado de segurança para cada proxy.

Monitoramento de APIs

A Apigee oferece uma plataforma abrangente de monitoramento de APIs que complementa os recursos de geração de relatórios de segurança. O monitoramento de APIs permite que as organizações detectem proativamente problemas de tráfego e desempenho da API. O monitoramento de APIs do Apigee funciona com o Apigee Edge para Public Cloud para fornecer 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 API 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 indesejado, incluindo ataques de clientes mal-intencionados. O Apigee Sense analisa o tráfego de solicitações da 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, em seguida, 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 atividades
  • Padrões geográficos

API8:2019 Injection

Descrição da ameaça

A injeção de dados não confiáveis, como SQL, NoSQL, analisadores XML, ORM, LDAP, comandos do SO e JavaScript, em solicitações de API pode resultar na execução de comandos indesejados ou em acesso não autorizado a dados. Os invasores alimentam a API com dados maliciosos usando os vetores de injeção disponíveis, como entrada direta, parâmetros, serviços integrados e assim por diante, esperando que eles sejam enviados 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 um DoS.

As práticas recomendadas para reduzir erros/ataques de injeção incluem definir estritamente os dados de entrada, como esquemas, tipos, padrões de string, realizar a validação de entrada, verificar limites e aplicá-los no momento da 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 do 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 para remover sequências de caracteres arriscadas e substituí-las 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 qualquer 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 do RegularExpressionProtection é a avaliação de payloads JSON e XML para conteúdo malicioso.

Nenhuma expressão regular pode eliminar todos os ataques baseados em conteúdo, e vários mecanismos precisam ser combinados para permitir 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 a entrada disponível com a 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.

Relatórios de segurança da API

À medida que as organizações se esforçam para desenvolver um framework de governança, a Apigee oferece recursos relacionados a relatórios de segurança de API, que auxiliam e fornecem às equipes de operação a visibilidade necessária para proteger APIs, fornecendo às equipes de operação os atributos de segurança das APIs para:

  • Garanta a adesão às políticas de segurança e aos requisitos de configuração.
  • Proteger dados sensíveis contra abuso interno e externo.
  • Identificar, diagnosticar e resolver incidentes de segurança de forma proativa.

API9:2019 Gerenciamento de recursos incorreto

Descrição da ameaça

O gerenciamento e a segregação de ambientes insuficientes permitem que invasores acessem endpoints de API com pouca segurança. A falta de salvaguardas de governança também causa exposição desnecessária de recursos descontinuados.

Essa ameaça pode ser resolvida usando 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 permita a colaboração entre as equipes e, ao mesmo tempo, aplique a separação de responsabilidades entre as partes interessadas de segurança e os desenvolvedores de API. Os limites e controles podem ser configurados e mantidos usando:

Organizações, ambientes e revisões: proteções virtuais e físicas que garantem o isolamento e um processo de promoção seguro nos 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 a documentação da API: depois que uma API é publicada no portal do desenvolvedor, é 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.

Relatórios de segurança: as partes interessadas em segurança têm visibilidade completa das APIs publicadas e da configuração de suporte delas. A adesão às políticas de segurança globais pode ser auditada e avaliada com base no perfil de risco de cada endpoint de API publicado.

Organizações e ambientes

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

Organizações: uma organização é o locatário de nível superior na Apigee. Ele permite a segregação total 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 misturar dados de produção, usuários e tráfego com ambientes mais baixos.

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 é levado durante o processo de promoção, evitando a exposição de configurações sensíveis a usuários sem privilégios.

Revisões: as revisões permitem que as APIs e os recursos individuais sejam promovidos sem problemas pelos ambientes.

Controle de acesso baseado em função

Para mitigar a API9, é necessário ter definições claras e separaçã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 ser limitadas a privilégios limitados por organização, ambientes ou permissões de configuração mais granulares. Como prática recomendada, considere limitar os privilégios para mudar o estado de implantação de APIs em ambientes e também para garantir que os desenvolvedores não possam acessar ou modificar bibliotecas de segurança globais (Flow Hooks). Esses papéis limitados evitam mudanças não solicitadas nas políticas de segurança globais que têm ampla cobertura nos endpoints publicados legados e atuais.

Gerenciamento de públicos-alvo para a 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. No Apigee, é possível agrupar suas APIs usando os conceitos de produto de API. Os produtos de API são definidos por pacotes de recursos e operações que se enquadram no mesmo contexto de negócios e segurança (por exemplo, plano de serviço, domínio de negócios, categoria, hierarquia da empresa etc.).

Com o portal integrado para desenvolvedores do Apigee, você pode publicar produtos de API e restringir a visibilidade do conteúdo publicado gerenciando públicos-alvo. Esse recurso obedece a uma estratégia de segmentação de conteúdo que está alinhada aos requisitos de negócios e segurança.

Ganchos de fluxo

Os processos de promoção e lançamento de APIs sempre precisam incluir processos de conformidade e certificação 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 os ciclos de lançamento ágeis.

A Apigee permite que você eleve as funções de governança de segurança aplicando políticas globais usando os Flow Hooks. Essas políticas globais podem ser gerenciadas como proteções privilegiadas que não podem ser modificadas pelos desenvolvedores de API, garantindo a separação de responsabilidades e promovendo a agilidade ao aplicar a segurança padrão e, por extensão, fornecendo conformidade de segurança para todas as APIs implantadas em um determinado ambiente de execução.

Figura: os limites 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 ágeis.

Relatórios de segurança

As auditorias de segurança têm o objetivo de avaliar e testar as políticas de segurança destinadas a proteger os dados e objetivos de negócios da sua organização. As APIs são interfaces públicas ou privadas padronizadas que precisam ser protegidas por um modelo de governança de segurança abrangente e, ao mesmo tempo, auditável.

Na Apigee, você tem acesso a relatórios de segurança especializados que ajudam a garantir a adesão às políticas definidas e permitem que as equipes de segurança tomem medidas com base em insights abrangentes sobre:

Tráfego de execução: uma visualização única de insights de tráfego de APIs sobre: servidores de destino, hosts virtuais, configuração de TLS, mudanças de tráfego por ambiente e muito mais.

Configuração: recurso de auditoria para a configuração de proxies de API que oferece visibilidade de ponta a ponta de todas as políticas aplicadas no nível do proxy de API e também o espectro de aplicação de fluxos compartilhados anexados nos níveis da organização ou do proxy.

Atividade do usuário: rastreie operações sensíveis realizadas pelos usuários da plataforma. Analise atividades suspeitas detalhando-as.

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 não sejam detectados. Portanto, é necessário ter uma estratégia para conseguir insights sobre eventos críticos que afetam sua empresa.

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

  • Política de gerenciamento de registros: documente e aplique regras para padronizar e controlar a quantidade de detalhes, os níveis, a integridade, o repositório centralizado e muito mais.
  • Política de gerenciamento de eventos: garanta que todos os eventos sejam rastreáveis até a origem. Além disso, os eventos precisam ser categorizados por criticidade e impacto nos negócios.
  • Relatórios e auditorias: as partes interessadas em segurança e operações precisam ter acesso 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. Estas ferramentas incluem:

Política de log de mensagens: crie streams de registro com base em dados de tráfego ou metadados do tráfego da API. Você tem a flexibilidade de decidir o nível de detalhes do fluxo usando a lógica condicional e os modelos de mensagem.

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

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

Análise: acesse e analise os metadados de tráfego históricos com relatórios prontos para uso e/ou personalizados. Crie e gerencie alertas com base nas tendências e entenda as anomalias de tráfego.

Monitoramento da 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 tomar medidas.