10 principais ameaças à API do OWASP

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

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

Introdução

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

Neste documento, discutiremos abordagens de proteção contra ataques comuns baseados em API, conforme identificado pelas dez principais ameaças de segurança de APIs de 2019 do OWASP. Um tema comum nas principais ameaças destacados pela lista mais recente é causado pelo posicionamento inadequado dos controles de autenticação e autorização, como a dependência na 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 acelerado do ecossistema de APIs, os abusos e usos indevidos de APIs que resultam na exfiltração de dados por invasores infelizmente 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 Operações de API avançadas, que incluem relatórios de segurança e recursos de detecção de anomalias. No entanto, projetar e implementar corretamente os recursos de segurança da Apigee é essencial para reduzir a probabilidade de ataques bem-sucedidos às APIs.

Os aplicativos do consumidor precisam ser considerados não confiáveis, ou "públicos", porque você não controla a plataforma em que o app está sendo executado. Considere que qualquer app público pode e será comprometido. Portanto, não é confiável que eles apliquem o controle de acesso (API1, API5), dados de resposta de filtro (API6) ou armazenem chaves secretas do cliente com segurança (API2), como chaves de API ou tokens de acesso. Algumas recomendações surgem após a análise dos 10 principais OWASP de 2019:

  • Determine os tipos de apps clientes que vão consumir suas APIs (SPA, dispositivos móveis ou baseadas em navegador) e projete os padrões apropriados de autenticação, autorização e segurança.
  • Sempre use os fluxos de OAuth ou OpenID Connect do “cliente público” (o uso de PKCE é altamente recomendado).
  • Pense na lógica de negócios do seu app, defina a especificação OpenAPI primeiro e crie proxies de API para filtrar todos os dados de resposta do back-end na Apigee. Nunca confie na lógica do código do app downstream para fazer isso.
  • Filtre todas as solicitações de dados que contenham PII específicas do usuário para permitir somente os dados do seu back-end que pertençam ao usuário solicitante.

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

Descrição da ameaça

A validação insuficiente de autorização de uma solicitação de acesso ao objeto permite que um invasor execute 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 oferece políticas VerifyApiKey, OAuth e JSON Web Token (JWT), que ajudam na proteção contra essa vulnerabilidade. Ainda assim, é essencial que essas políticas sejam configuradas corretamente para evitar essa ameaça.

Para evitar essa ameaça, é importante que as equipes de desenvolvimento e segurança de aplicativos colaborem de perto. Autorização é, por natureza, um assunto complexo, e a autorização eficaz e detalhada requer uma compreensão profunda da lógica de negócios do aplicativo.

Há dois aspectos principais a serem considerados da perspectiva da implementação da Apigee:

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

Integridade do token de acesso

É fundamental confirmar se o token fornecido pelo cliente solicitante não foi adulterado usando o fluxo correto do OAuth ou do OpenID Connect, além do mecanismo apropriado de validação ou assinatura de credenciais. A Apigee oferece suporte a todos os fluxos 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: uso de 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: usa uma 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 as declarações extraídas de um token de acesso puderem ser usadas para avaliar e autorizar diretamente uma solicitação de objeto da 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 condicional.

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.

Com 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 coletar mais informações de reivindicaçã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 corrompida

Descrição da ameaça

Políticas de autenticação de usuários mal implementadas permitem que invasores falsifiquem a identidade de usuários legítimos, aproveitando as falhas nas implementações de autenticação. Alguns princípios de autenticação que você precisa ter em mente ao implementar abordagens de autenticação incluem:

  • Sempre autentique o user agent (o aplicativo) e o usuário solicitante
  • Use padrões de autenticação e autorização delegados e evite passar 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 por parte dos bots

Em um paradigma externo, o design da API é baseado nos casos de uso dos dados dos consumidores, e não na estrutura dos dados atuais nos sistemas de back-end. A segurança é um elemento essencial ao projetar APIs para consumidores externos. Tradicionalmente, os sistemas de back-end não são criados com implementações de autenticação fortes o suficiente para exposição em redes públicas. É aqui que a Apigee, combinada a uma solução de gerenciamento de identidade e acesso, pode oferecer soluções fortes para se proteger contra essa ameaça.

Há alguns elementos importantes a serem considerados aqui. Ambos serão abordados nas próximas seções:

  • Design de segurança: como aproveitar 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 sejam usados de maneira consistente em todos os produtos de API publicados.
  • Segurança operacional: detecção de comportamentos suspeitos ou anômalos e tentativa de burlar ou de burlar proxies de API autenticados por força bruta.

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 da 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 aplicativo que 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 essa solução.

Os RFCs do OpenID Connect e do OAuth fornecem um amplo número de fluxos de autenticação e autorização delegados, bem como de agentes envolvidos neles. Esse é um tópico complexo, e não surpreende que a autenticação corrompida seja uma das principais ameaças da API OWASP. Fornecer uma introdução abrangente sobre a implementação correta de padrões de identidade está fora do escopo deste documento. Ainda assim, a Apigee tem muitos recursos adicionais para entender melhor os fluxos de OAuth, como este e-book e este webcast, além do exemplo de implementação.

Políticas de autenticação

As políticas da Apigee que ajudam a lidar com questões 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 contínua geral em um proxy de API;
  • Políticas de cotas, para definir limites de taxa refinados para 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, para armazenar em cache os tokens de acesso armazenados com base nos tempos de expiração definidos, bem como a capacidade de invalidate as 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 "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 relacionados à autenticação forem definidos, é absolutamente essencial 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 função (RBAC)

Não importa se você é uma grande empresa ou uma pequena startup, evitar erros de configuração começa ao garantir que apenas as pessoas e equipes certas possam acessar e modificar as configurações de proxy de API. Os programas de API recebem suporte de equipes multidisciplinares em toda a organização. É absolutamente essencial que cada equipe receba apenas as permissões necessárias para trabalhar como parte da jornada da API.

A Apigee oferece recursos para gerenciar o acesso baseado em papéis. Com ela, é possível atribuir usuários a papéis predefinidos ou criar papéis personalizados para atender às equipes de API. Definir e gerenciar corretamente a atribuição de papéis é fundamental para permitir o escalonamento seguro do seu programa de API. Também é possível usar a federação para fazer a integração com seu diretório corporativo atual e reduzir a necessidade de gerenciar um segundo conjunto de credenciais de administrador na Apigee.

Fluxos compartilhados

Os fluxos compartilhados permitem que você defina políticas e recursos em um objeto reutilizável que pode ser implementado em proxies de API. Por exemplo, com suas equipes de segurança, você pode ter projetado de maneira colaborativa vários padrões de design de autenticação com base no tipo de aplicativo 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 atual usando a política de chamada de fluxo.

Figura: 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 organização possam modificar os padrões de autenticação e definir os fluxos de autenticação compartilhados, garanta que os proxies desenvolvidos pelas suas equipes de API usem esses padrões de autenticação de maneira consistente.

O novo recurso de Operações de API avançadas da Apigee inclui relatórios de segurança avançados, que permitem que as equipes de operações e segurança visualizem relatórios com facilidade sobre todos os proxies de API e se concentra na adesão a políticas de segurança, como o uso de fluxos compartilhados. A geração de relatórios, a geração de registros e os alertas são elementos fundamentais da segurança da API, que serão discutidos com mais detalhes em API10: geração de registros insuficiente. No entanto, para evitar riscos de autenticação corrompido, eles são extremamente úteis para garantir a adesão aos padrões de autenticação definidos, implementados como fluxos compartilhados.

Segurança operacional

Quando suas APIs estiverem em produção usando os padrões de autenticação corretos com o gerenciamento de tráfego de referência em vigor, sua equipe de SecOps também precisará ser capaz de monitorar e responder a atividades suspeitas, que geralmente começam com tentativas de comprometer credenciais de autenticação.

Apigee Sense

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

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

  • Comportamento automatizado que se integra ao comportamento humano
  • Tentativas persistentes do mesmo IP
  • Taxas de erro incomuns
  • Solicitações de cliente suspeitas
  • Rastreamento de dados
  • Coleta de chaves e ataques de força bruta de autenticação
  • bursts de atividades;
  • 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, as operações avançadas da API incluem definições de detecção de anomalias e alertas avançados.

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

As operações de APIs avançadas usam o mecanismo de alerta atual do Monitoring da API para adicionar os seguintes tipos de alerta avançados:

  • Alertas de trânsito total: Gera um alerta quando o tráfego muda por uma porcentagem especificada durante um período. Por exemplo, é possível emitir um alerta quando o tráfego aumentar 5% ou mais por uma hora ou diminuir 10% ou mais por uma semana.
  • Alertas de anomalias. O Edge detecta problemas de tráfego e desempenho em vez de você ter que predeterminá-los por conta própria. É possível criar um alerta para essas anomalias
  • Alertas de expiração do TLS. Gera 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 de base, ele poderá acessar dados sensíveis.

Um dos princípios de design "de fora" da Apigee para o design de APIs é a parsônia de dados. Trabalhe com designers e desenvolvedores de UX para expor dados apenas pelas APIs que são necessárias na IU do seu app. Os sistemas de back-end não foram criados para padrões de uso público. Portanto, uma das primeiras tarefas do primeiro projeto 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 dos princípios de design da Apigee é a reutilização. Deixando de lado as questões de segurança, depender de um app para filtrar os dados fornecidos por uma API resulta no requisito de portabilidade dessa lógica de filtragem em todas as plataformas para as quais você desenvolver 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 os quais 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 mostram 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 confidenciais do ambiente sobre seus serviços de back-end a invasores

Como reescrever respostas e solicitações

Geralmente, 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 criado para permitir que você implante produtos de API públicos, 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 de código
  • Tratamento de falhas

Política de atribuição de mensagens

A política Atribuir mensagem altera ou cria novas mensagens de solicitação e resposta durante o fluxo do 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 as propriedades de uma mensagem para outra
  • Remova cabeçalhos, parâmetros de consulta, parâmetros de formulário e/ou payloads de uma mensagem
  • Defina o valor das propriedades atuais em uma mensagem

Com o recurso de atribuição de mensagens, você normalmente adiciona, altera ou remove propriedades da solicitação ou da resposta. No entanto, também é possível usar o recurso "Atribuir mensagem" para criar uma solicitação ou mensagem de 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 regras complexas de processamento e regravação de dados com complexidade além da capacidade da política de atribuição de mensagens, é possível usar linguagens processuais como JavaScript, Java ou Python. É possível adicionar um código personalizado a um proxy de API e, em seguida, chamá-lo usando as políticas adicionadas ao fluxo de proxy. O suporte a código processual foi projetado para facilitar a implementação de 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 idiomas compatíveis: política de JavaScript, de frase de destaque Java e Python Script.

Gerenciamento de falhas

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

Fluxos compartilhados

Fluxos compartilhados podem ser usados para impor a padronização de 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

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

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

  • Políticas de cotas e controle de pico como controles preventivos para colocar limites de tráfego em solicitações de API de entrada.
  • Apigee Sense, para detectar e responder dinamicamente a ataques acionados por bots
  • Monitoramento e alertas avançados de APIs como controles de detecção para receber alertas sobre ataques DDoS em andamento.

Limitação de taxa com políticas de cotas e de suspensão de pico

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

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

Spike Arrest

A política Spike Arrest protege contra picos de tráfego. Esta 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 contínuo definível na política.

Cotas

A política de cotas 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 para ser a mesma para todos os apps que acessam o proxy de API ou 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 que a prisão de picos e, em geral, deve ser usada simultaneamente a 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 sistema autônomo específicos, com base nesses clientes ou locais que apresentem comportamento malicioso ou suspeito. O Apigee Edge aplica essas ações às solicitações antes que elas sejam processadas pelos proxies de API. Por exemplo, um intervalo de IP ou um cliente específico exibindo um comportamento de "palpite bruto" pode ser detectado e bloqueado ou sinalizado.

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

Use um alerta de tráfego para gerar uma notificação quando o tráfego de um ambiente, proxy ou região mudar a uma porcentagem especificada ao longo de um período. Esse recurso pode emitir um alerta dinamicamente quando o tráfego desviar significativamente da capacidade esperada, como aconteceria durante um ataque DDoS. Esses alertas podem ser facilmente enviados 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 que ele não tem autorização para acessar. Por exemplo, um invasor pode modificar ou excluir dados que só tem autorização para ler se um endpoint da API não validar o verbo da solicitação HTTP, substituindo um GET por 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 visualize os dados de outro usuário simplesmente alterando o caminho em uma solicitação.

Esse tipo de ameaça destaca o valor de usar a Apigee como camada de mediação e abstração, já que muitos sistemas de back-end, que não são projetados para acesso público, podem, por padrão, fornecer um único endpoint para executar várias funções de lógica de negócios, incluindo até mesmo 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 produto de API e implemente a segmentação lógica de funcionalidades ao usar as práticas recomendadas RESTful para projetar os caminhos e os recursos expostos pelos proxies, produtos e recursos de apps da API Apigee.
  • Quem está acessando seus recursos da API? Defina os perfis 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 da Apigee, conforme descrito em API1 e API2.
  • Como suas políticas de acesso estão sendo aplicadas? Use falhas e fluxos 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 aplicativos 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.

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

Figura: os recursos da API agrupados em um produto de API podem vir de uma ou mais APIs. Assim, é possível 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.

As abordagens de autorização consideradas acima para a Autorização de objeto corrompido API1:2019 abordam o controle de acesso detalhado no nível do objeto, mas é igualmente importante lidar com o controle de acesso granular no nível da função. O usuário que fez a solicitação tem permissão para solicitar esse caminho do URL? Em geral, esse tipo de política é definido por perfil de usuário (cliente, funcionário, administrador, desenvolvedor interno ou terceirizado).

Para reduzir o risco de configurações incorretas, 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, seja com escopos do OAuth ou declarações JWT.

Solicitar validação com fluxos condicionais

Em nível básico, uma chamada da 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 nesta 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 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 quais funções são permitidas pelas APIs, a próxima etapa é restringir as solicitações que estão fora disso por meio dos recursos do produto Apigee:

  • Lógica condicional e políticas de criação de falhas 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 se proteger contra ataques baseados em conteúdo usando payloads de solicitações JSON ou XML malformados.

API6:2019 Atribuição em massa

Descrição da ameaça

Os dados não filtrados fornecidos por APIs para apps clientes permitem que os invasores adivinhem as propriedades dos objetos usando solicitações ou usem convenções de nomenclatura de endpoints para ter pistas sobre onde realizar modificações não autorizadas ou acessar 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 tente adivinhar os detalhes de implementação subjacentes dos sistemas de back-end, bem como os nomes de propriedades 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, pode ativar vulnerabilidades de execução remota de código.

Existem dois aspectos que geralmente permitem esse tipo de ameaça:

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

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

Política de filtragem da especificação OpenAPI

A política OASValidation (Validação de especificação da OpenAPI, na sigla em inglês) permite validar uma solicitação ou mensagem de resposta recebida em relação a uma especificação da OpenAPI 3.0 (JSON ou YAML). Com ela, é possível:

  1. Projete a 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. Valide as solicitações recebidas em relação ao esquema de dados definido na especificação do OAS, incluindo basepath, verb, request message policy e parameters.

Política de validação de mensagens de SSO

A política de validação de mensagens SOAP permite validar solicitações baseadas em XML por meio da validação de uma mensagem XML em relação a um esquema XSD ou da validação de uma mensagem SSO com base em uma definição WSDL. Além disso, é possível 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 entre origens (CORS) permissivo e mensagens de erro detalhadas contendo informações sensíveis. Os invasores geralmente tentam encontrar falhas não corrigidas, endpoints comuns ou arquivos e diretórios desprotegidos para conseguir acesso ou conhecimento não autorizado sobre o sistema que querem atacar. Configurações incorretas de segurança não expõem apenas dados confidenciais do usuário, mas também detalhes do sistema que podem comprometer completamente o servidor. Além disso, alguns outros casos de uso de vulnerabilidades para configurações incorretas de segurança podem incluir:

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

Há várias etapas que as organizações podem seguir para enfrentar e reduzir os desafios relacionados a configurações incorretas de segurança, incluindo:

  1. Estabelecer e padronizar processos de aumento da proteção e aplicação de patches
  2. Como desenvolver a governança em torno do ecossistema de APIs
  3. Como restringir o acesso administrativo e ativar auditorias e alertas

Fluxos compartilhados e ganchos de fluxo

A Apigee oferece suporte ao conceito de fluxo compartilhado, que permite que os desenvolvedores de APIs combinem políticas e recursos em um grupo reutilizável. Ao capturar a funcionalidade reutilizável 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 dentro de proxies de API individuais ou ir além e colocar fluxos compartilhados em hooks 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 de APIs

À medida que as organizações se esforçam para desenvolver uma estrutura de governança, a Apigee fornece recursos relacionados à geração de relatórios de segurança da API, que ajudam as equipes de operação com a visibilidade necessária dos atributos de segurança das APIs para:

  • Garantir a conformidade com as políticas de segurança e os requisitos de configuração
  • Proteja dados sensíveis contra abusos internos e externos
  • Identifique, diagnostique e resolva incidentes de segurança de forma proativa

Os relatórios de segurança da Apigee oferecem insights detalhados para equipes de operações, garantindo a conformidade com as políticas e os requisitos de configuração, proteger APIs contra abusos internos e externos e identificar e resolver rapidamente incidentes de segurança.

Com os relatórios de segurança, os administradores de segurança entendem 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. Com essas informações, é possível ajustar a configuração para garantir que você tenha o nível adequado de segurança para cada proxy.

Monitoramento de APIs

A Apigee fornece uma plataforma abrangente de monitoramento de APIs que complementa os recursos de relatórios de segurança. O monitoramento de APIs permite que as organizações detectem proativamente o tráfego e os problemas de desempenho. O monitoramento de APIs da Apigee funciona com o Apigee Edge para nuvem pública 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 APIs da Apigee fornece uma ampla variedade de ferramentas para monitorar, investigar e agir em relação aos problemas. Ele aproveita os melhores recursos de inteligência do Google Cloud Platform.

Apigee Sense

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

Usando essa análise, as organizações podem identificar clientes que fazem solicitações indesejadas e, em seguida, agir 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 integra ao comportamento humano
  • Tentativas persistentes do mesmo IP
  • Taxas de erro incomuns
  • Solicitações de cliente suspeitas
  • Rastreamento de dados
  • Coleta de chaves
  • bursts de atividades;
  • Padrões geográficos

Injeção API8:2019

Descrição da ameaça

A injeção não confiável de dados, como SQL, NoSQL, analisadores de XML, ORM, LDAP, comandos do SO e JavaScript, em solicitações de API pode resultar na execução de comandos indesejados ou acesso não autorizado a dados. Os invasores vão alimentar a API com dados maliciosos por meio de quaisquer 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 vulnerabilidades e fuzzers. Uma injeção bem-sucedida pode levar à divulgação de informações que afetam a confidencialidade e a perda de dados ou, em alguns casos, também pode levar a ataques 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, executar validação de entrada, verificações de limite e aplicá-las no ambiente 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 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 a transforme 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 de XML ou payload JSON) e avalia esse conteúdo em relação a 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 da 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 permitir uma 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 com a plataforma Apigee:

Validar tipos de conteúdo

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

Relatórios de segurança de APIs

À medida que as organizações se esforçam para desenvolver uma estrutura de governança, a Apigee fornece recursos relacionados aos relatórios de segurança de APIs, que auxiliam e oferecem às equipes de operação a visibilidade necessária para proteger APIs, fornecendo às equipes de operações a visibilidade de que precisam de atributos de segurança das APIs para:

  • Garantir a conformidade com as políticas de segurança e os requisitos de configuração.
  • Proteger dados sensíveis contra abusos internos e externos.
  • Identificar, diagnosticar e resolver incidentes de segurança de maneira proativa.

API9:2019 Gerenciamento de recursos impróprios

Descrição da ameaça

O gerenciamento insuficiente e a segregação do ambiente permitem que os invasores acessem endpoints da API não protegidos. A falta de proteções de governança também causa exposição desnecessária de recursos descontinuados.

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

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

Controle de acesso baseado em função: somente as pessoas necessárias nas equipes da API terão permissões para gerenciar alterações de configuração e também o processo de promoção.

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

Ganchos 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 de segurança têm visibilidade de ponta a ponta das APIs publicadas e das configurações de suporte delas. A aderência à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 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 de APIs e da configuração de suporte delas.

Organizações: uma organização é o locatário de nível superior na Apigee. Assim, você tem total segregação no tráfego, na configuração e nos usuários. Como prática recomendada de governança, tenha organizações separadas de produção e não produção. Essa prática evita a mistura eficaz de dados de produção, usuários e tráfego com ambientes inferiores.

Ambientes: as APIs na Apigee podem ser promovidas usando vários estados de implantação. Cada estado é vinculado a um contexto de execução. O contexto do ambiente não é transferido durante o processo de promoção, evitando a exposição da configuração confidencial a usuários sem privilégios.

Revisões: as revisões permitem que APIs e recursos individuais sejam promovidos com facilidade nos ambientes.

Controle de acesso baseado em função

Para mitigar a API9, é fundamental ter definições claras e separação de tarefas entre as partes interessadas de segurança e os desenvolvedores de API. Conforme mencionado anteriormente neste documento, a Apigee tem recursos flexíveis de controle de acesso baseado em papéis que permitem atribuir permissões a papéis personalizados. Para essa ameaça específica, é possível definir o escopo dos papéis para ter 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 alterar o estado de implantação das APIs por meio de ambientes e também para garantir que os desenvolvedores não consigam acessar ou modificar bibliotecas de segurança globais (flow hooks). Esses papéis limitados impedirão alterações não solicitadas nas políticas de segurança globais que têm ampla cobertura em endpoints legados e publicados atuais.

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

O Portal do desenvolvedor é um componente essencial para o sucesso da sua estratégia de API. Ele permite que você mantenha 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 da 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 do desenvolvedor integrado da Apigee, é possível publicar produtos de API e restringir a visibilidade do conteúdo publicado gerenciando públicos-alvo. Esse recurso está em conformidade com uma estratégia de segmentação de conteúdo alinhada aos requisitos de negócios e 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 apropriadas precisam criar proteções que garantam a separação de responsabilidades e, ao mesmo tempo, mantenham ciclos de lançamento ágeis.

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

Figura: proteções privilegiadas podem ser configuradas na Apigee por hooks de fluxo e fluxos compartilhados. As partes interessadas na área de segurança são responsáveis por manter as políticas globais relacionadas à segurança. Esses recursos garantem separação de responsabilidades e promovem ciclos de vida ágeis de desenvolvimento.

Relatórios de segurança

O objetivo das auditorias de segurança é avaliar e testar as políticas de segurança criadas para proteger os dados e os 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 ajam com base em insights abrangentes sobre:

Tráfego do ambiente de execução: uma visualização completa para insights sobre o tráfego de APIs sobre: servidores de destino, hosts virtuais, configuração de TLS, alterações de tráfego por ambiente e muito mais.

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

Atividade do usuário: acompanhe operações confidenciais realizadas pelos usuários da plataforma. Analise as atividades suspeitas com um detalhamento sobre as atividades suspeitas.

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

Descrição da ameaça

Com a geração de registros, monitoramento e alertas insuficientes, os ataques em andamento não são detectados. Por isso, é necessário ter uma estratégia para conseguir insights sobre eventos críticos que afetam os negócios.

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 o detalhamento, os níveis e a integridade dos registros, um 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 importância e impacto nos negócios.
  • Relatórios e auditorias: as partes interessadas de segurança e operações precisam ser capazes de acessar e reagir a registros e eventos em tempo real. Além disso, os ciclos de reforço podem ser realizados pelas partes interessadas para ajustar os padrões de detecção com base nos dados históricos

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

Política de geração de registros de mensagens: crie streams de registros com base em dados ou metadados de tráfego do tráfego da API. Você tem flexibilidade para decidir o detalhamento do stream aproveitando a lógica condicional e os modelos de mensagens.

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

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

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

Monitoramento de APIs: conforme 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 atuados posteriormente.