10 principais ameaças ao aplicativo da Web

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.

Visão geral

Os ecossistemas de API sofrem vários ataques de clientes externos e internos. Oferecer e usar APIs cria oportunidades incríveis para os provedores de serviços, mas também apresenta alguns riscos de segurança. Os desenvolvedores precisam estar cientes desses desafios e resolvê-los ao criar e usar APIs.

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.

Com o Apigee, a camada de proxy de API pode detectar, bloquear e informar solicitações de API com formato incorreto do cliente antes que elas sejam processadas nos sistemas de back-end, reduzindo o risco e protegendo seus serviços. As solicitações com formato incorreto podem incluir qualquer componente que componha o protocolo do nível do aplicativo HTTP:

  • URL
  • Cabeçalhos
  • Caminho
  • Payload

As solicitações de API com formato incorreto podem ser de clientes conhecidos ou desconhecidos desenvolvidos por desenvolvedores externos, internos ou bots maliciosos.  Esses tipos de solicitações representam a maioria das ameaças da OWASP, mas há outros componentes da camada de proxy da API que podem reduzir riscos, como mascaramento de dados, registro, administração e assim por diante.

A plataforma inteligente de gerenciamento de APIs da Apigee permite que você resolva as principais vulnerabilidades de segurança de API do OWASP de forma simples, adotando uma abordagem focada no consumo para projetar suas APIs e conectá-las aos sistemas de back-end. Confira a seguir uma lista de políticas/configurações recomendadas pela Apigee para as principais ameaças do OWASP para REST.

Soluções da Apigee para as 10 principais ameaças da OWASP de 2017

Há muitas preocupações de segurança quando se trata de criar e proteger aplicativos da Web. A OWASP lançou a lista das 10 principais ameaças de segurança da OWASP 2017 (em inglês) para aplicativos da Web.  Embora um aplicativo da Web tenha muitas partes, a maioria dos apps da Web modernos depende muito das APIs REST.  A Apigee não é destinada a processar todas as necessidades de segurança de um aplicativo da Web, mas pode desempenhar um papel fundamental na proteção das APIs REST. Confira a seguir as principais ameaças de segurança do OWASP com descrições de como usar o Apigee para ajudar a resolver essas ameaças.

A1:2017 - Injeção

Para se proteger contra injeções de dados não confiáveis, como SQL, NoSQL, LDAP e JavaScript, que podem resultar na execução de comandos não intencionais ou no acesso não autorizado a dados, a Apigee oferece várias políticas de validação de entrada para verificar se os valores fornecidos por um cliente correspondem às expectativas antes de permitir o processamento. 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.

Há várias abordagens para validar a entrada com a plataforma Apigee:

Validar tipos de conteúdo:

A2:2017 - Autenticação e gerenciamento de sessões corrompidos

Os invasores podem acessar senhas, tokens de sessão e chaves para se passar por outros usuários aproveitando falhas de implementação em aplicativos. Esse é um problema de implementação, não de produto.  A Apigee fornece políticas VerifyApiKey, OAuth e JSON Web Token (JWT), que ajudam a proteger contra essa vulnerabilidade.

Validação de chave de API

A validação de chave de API é a forma mais simples de segurança baseada em aplicativo que pode ser configurada para uma API. Um app cliente simplesmente apresenta uma chave de API com a solicitação e, em seguida, o Apigee Edge, por meio de uma política anexada a um proxy de API, verifica se a chave de API está em um estado aprovado para o recurso solicitado.

A Apigee oferece suporte para a geração e validação de chaves de API. A Apigee gera uma chave de API e um secret quando um app para desenvolvedor é criado e aprovado e vinculado a um ou mais produtos de API.

O termo "chaves de API" às vezes pode significar coisas diferentes. Na Apigee, quando a relação entre o app e o produto é formada, ela gera um ID e um secret do cliente.  Alguns se referem ao ID e ao secret como a chave de API. Alguns se referem apenas ao ID do cliente como a chave de API. Na interface do Edge, você vai encontrar "chave do consumidor" e "secret do consumidor".

Na política VerifyAPIKey, apenas o ID do cliente ou a "chave de consumidor" é verificado. Os desenvolvedores recebem uma chave de consumidor quando registram o app na Apigee e o associam a um produto de API. Os desenvolvedores incluem a chave do consumidor em chamadas que o app faz para proxies de API agrupados no produto de API.

A Apigee também oferece suporte à capacidade de importar chaves de API atuais de fontes externas.

Para tipos de concessão do OAuth, o ID do cliente e a chave secreta são usados.

OAuth 2.0

O framework de autorização OAuth 2.0 permite que um aplicativo de terceiros receba acesso limitado a um serviço HTTP em nome de um proprietário de recurso, orquestrando uma interação de aprovação entre o proprietário do recurso e o serviço HTTP ou permitindo que o aplicativo de terceiros receba acesso em nome próprio.

Com as políticas do OAuth 2.0 da Apigee, você pode implementar e personalizar os quatro tipos de concessão do OAuth 2.0. A aplicação de tokens de acesso do OAuth pode ser feita usando a política OAuthv2. O consumidor precisa estar registrado e ter um app aprovado que concedeu acesso à API. Em troca, eles vão receber um ID e uma chave secreta do cliente da API. O consumidor precisa passar por uma das permissões do OAuth para ser autenticado, o que concede a ele um token de acesso opaco. Esse token pode ser usado para controlar o acesso à API.

JWT

Os JSON Web Tokens (JWTs) são comumente usados para compartilhar declarações ou asserções entre aplicativos conectados. A Apigee oferece suporte a JWT usando três políticas.

  • Tokens GenerateJWT (compatível com assinaturas HS256 e RS256)
  • Tokens ValidateJWT
  • DecodeJWT tokens sem validação

A3:2017 - Exposição de dados sensíveis

Os invasores visam dados sensíveis, como detalhes de cartão de crédito, CPF ou CNPJ, credenciais de login, informações de identificação pessoal (PII) e documentos fiscais para cometer roubo de identidade, roubo de dinheiro, fraudes e outros crimes. Os aplicativos da Web precisam implementar a criptografia, tanto em repouso quanto em trânsito, e outras estratégias para garantir a proteção de dados sensíveis.

O TLS (Transport Layer Security, cujo antecessor é o SSL) é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor da Web e um cliente da Web, como um navegador ou um app. A Apigee oferece suporte a TLS unidirecional e bidirecional.

O TLS de sentido único (cliente se conectando à API que atua como servidor) tem suporte pelo uso de uma configuração de host virtual. Um host virtual pode ser configurado para TLS unidirecional ou bidirecional.

O TLS de saída (Apigee como um cliente se conectando ao serviço de back-end) é compatível com o uso de uma configuração de servidor de destino.  Um servidor de destino pode ser configurado para TLS unidirecional ou bidirecional.

A Apigee oferece suporte a muitas opções de configuração do TLS.

A aplicação do TLS bidirecional garante que o cliente esteja usando um certificado que já foi integrado ao Apigee. O OWASP também fornece práticas recomendadas de TLS.

Na Apigee híbrida, o TLS está disponível na entrada por um alias de host, que é um conceito semelhante a um host virtual.

Confira a seguir as diretrizes para proteger dados sensíveis:

  • Use uma plataforma compatível com TLS unidirecional e bidirecional, que protege no nível do protocolo.
  • Use políticas como Política de atribuição de mensagem e Política de JavaScript para remover dados sensíveis antes que eles sejam retornados ao cliente.
  • Use técnicas padrão do OAuth e considere adicionar HMAC, hash, estado, nonce, PKCE ou outras técnicas para melhorar o nível de autenticação de cada solicitação.
  • Use as configurações de mascaramento de dados para ocultar dados sensíveis na ferramenta Edge Trace.
  • Tenha cuidado ao armazenar dados sensíveis no cache (ou criptografe dados sensíveis armazenados no cache). No Edge, é possível criptografar dados sensíveis em repouso em mapas de chave-valor.

A4:2017 - XML External Entities

Os sistemas ou aplicativos que processam XML precisam processar "referências de entidade externa" em XML, ou seja, referências a arquivos ou dados que são substituídos pelos dados reais durante o processamento do XML. Se os aplicativos ou processadores XML forem antigos ou mal implementados, os invasores poderão invadir os dados e usá-los para roubar informações ou lançar vários tipos de ataques no sistema, como negação de serviço.

A política ExtractVariables da Apigee permite extrair o conteúdo de uma solicitação ou resposta e atribuir esse conteúdo a uma variável. É possível extrair qualquer parte da mensagem, incluindo cabeçalhos, caminhos de URI, payloads JSON/XML, parâmetros de formulário e parâmetros de consulta. A política funciona aplicando um padrão de texto ao conteúdo da mensagem e, ao encontrar uma correspondência, define uma variável com o conteúdo da mensagem especificada.

A Apigee tem um analisador XML integrado como parte da plataforma que usa XPath para extrair dados. Ela também tem uma política XMLThreatProtection para proteger contra payloads XML maliciosos.

A5:2017 - Controle de acesso corrompido

Depois que os usuários fazem login e têm acesso a um sistema, é necessário implementar controles de autorização adequados para que eles possam ver e fazer apenas o que têm permissão. Sem controles de acesso fortes, os invasores podem acessar dados não autorizados e, muitas vezes, sensíveis ou manipular dados e o comportamento do sistema de forma maliciosa.

A Apigee é compatível com uma abordagem em camadas para implementar controles de acesso e evitar que os usuários mal-intencionados façam alterações não autorizadas ou acessem o sistema.

Controles de acesso para a interface do Edge

Controles de acesso para o portal do desenvolvedor da Apigee

  • Configure o logon único com o provedor de identidade da sua empresa.
  • Configure o controle de acesso baseado em função (RBAC) para permitir que os usuários acessem apenas a funcionalidade e a configuração necessárias nos portais de desenvolvedores baseados no Drupal.
  • Configure portais do desenvolvedor para mostrar produtos de API específicos de acordo com o papel do usuário.
  • Configure o portal para mostrar ou ocultar conteúdo com base no papel do usuário.

Controles de acesso para o ambiente de execução da API Apigee

  • O acesso às APIs pode ser aplicado com chaves de API, tokens OAuth, escopos OAuth, certificados e outras técnicas.
  • O provedor de API configura quais recursos estão disponíveis definindo um produto de API. O acesso é concedido manualmente na interface, pela API Management ou pelo portal do desenvolvedor. Quando o app de um desenvolvedor recebe acesso a um produto de API, ele recebe um ID de cliente e um secret que são usados no processo de autenticação.
  • A Apigee pode ser integrada a qualquer provedor de identidade para executar o OAuth.
  • A Apigee pode gerar tokens JWT ou outras técnicas para enviar a identidade do usuário aos serviços de destino. Os serviços de destino podem usar essa identidade para restringir o acesso a serviços e dados conforme necessário.

A6:2017-Configuração incorreta de segurança

As configurações incorretas de segurança são fáceis de ignorar, muitas vezes porque os administradores e desenvolvedores confiam erroneamente que os sistemas que usam são inerentemente seguros. A configuração incorreta de segurança pode acontecer de várias maneiras, como confiar em configurações padrão ou criar configurações parciais que podem ser inseguras, permitindo que mensagens de erro contenham detalhes confidenciais, armazenando dados na nuvem sem controles de segurança adequados, configurando incorretamente cabeçalhos HTTP e assim por diante. A plataforma Apigee oferece vários mecanismos para controlar, gerenciar e monitorar configurações de segurança, incluindo fluxos compartilhados reutilizáveis.

Um fluxo compartilhado 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.

As versões do produto Apigee garantem proteção contra bibliotecas com vulnerabilidades. A Apigee pode lançar outros patches ou atualizações se novas vulnerabilidades forem encontradas. A nuvem pública do Edge é corrigida automaticamente. Os clientes do Edge para nuvem privada (local) precisam aplicar os patches do produto por conta própria.

A7:2017-Scripting em vários locais (XSS)

O scripting em vários locais (XSS) permite que invasores executem scripts em navegadores da Web para controlar sessões do usuário, manipular sites ou afetar usuários de maneira mal-intencionada de outras maneiras. Os problemas de XSS não estão necessariamente relacionados a APIs, mas a Apigee oferece políticas de proteção contra ameaças que podem ser aproveitadas para proteger contra XSS na API.  Usando expressões regulares, com a política RegularExpressionProtection ou política JavaScript, verifique os valores de payload e parâmetro para JavaScript e outros ataques por injeção.

O CORS, uma das soluções comumente implementadas na política de mesma origem que é aplicada por todos os navegadores, pode ser implementado usando a política AssignMessage.

A8:2017 - Desserialização não segura

Os invasores podem usar falhas na desserialização para diferentes tipos de ataques, como repetição, escalonamento de privilégios e injeção. A desserialização insegura também pode ativar a execução remota de código.

A Apigee não recomenda a desserialização. No entanto, a política JSONThreatProtection e a política RegularExpressionProtection podem ajudar a proteger contra payloads JSON maliciosos. A política do JavaScript também pode ser usada para verificar payloads em busca de conteúdo malicioso. O cache e outras políticas podem ser usados para se proteger contra ataques de repetição. No nível da infraestrutura, a plataforma Apigee também tem proteções integradas para proteger processos em execução.

A9:2017 - Como usar componentes com vulnerabilidades conhecidas

Como os frameworks, as bibliotecas e os módulos são executados com execução completa e acesso CRUD, os invasores podem aproveitar as vulnerabilidades do componente para atacar sistemas.

Os lançamentos regulares de produtos da Apigee garantem proteção contra vulnerabilidades de componentes, especialmente quando vulnerabilidades específicas são descobertas. A nuvem pública do Apigee recebe patches automaticamente, e o Apigee notifica os clientes do Edge para nuvem privada quando os patches no local estão disponíveis para instalação.

A10:2017: geração de registros e monitoramento insuficientes

Quando você não realiza o registro, o monitoramento e o gerenciamento de incidentes adequadamente nos seus sistemas, os invasores podem realizar ataques mais profundos e prolongados aos dados e ao software.

A Apigee tem várias maneiras de executar a geração de registros, o monitoramento, o tratamento de erros e a geração de registros de auditoria.

Logging

  • As mensagens de registro podem ser enviadas para o Splunk ou outro endpoint do syslog usando a política MessageLogging.
  • É possível extrair dados de análise da API pela API Analytics e importá-los ou exportá-los para outros sistemas.
  • No Edge for Private Cloud, é possível usar a política MessageLogging para gravar em arquivos de registro locais. Os arquivos de registro de cada um dos componentes em execução também estão disponíveis.
  • A política JavaScript pode ser usada para enviar mensagens de registro a um endpoint de geração de registros REST de maneira síncrona ou assíncrona.

Monitoramento

Tratamento de erros

A Apigee oferece um mecanismo de tratamento de falhas eficiente e versátil para proxies de API. Assim como um programa Java captura exceções, os proxies de API podem identificar falhas e determinar como retornar respostas apropriadas aos clientes. O tratamento de falhas personalizado da Apigee permite que você adicione funcionalidades, como a geração de registros de mensagens, sempre que ocorrer um erro.

Registros de auditoria

A plataforma Apigee mantém um registro de auditoria que rastreia as alterações em proxies de API, produtos e histórico da organização.  Esse registro está disponível na interface ou na API Audits.

Soluções da Apigee para vulnerabilidades do OWASP de 2013

Quando o OWASP atualizou a lista para 2017, algumas vulnerabilidades da lista de 2013 foram deixadas de fora. Elas ainda são ameaças válidas. As seções a seguir descrevem como lidar com essas ameaças com o Apigee.

A8:2013 - Falsificação de solicitação entre sites (CSRF)

As solicitações de falsificação entre sites permitem que invasores encaminhem os detalhes de autenticação, o cookie de sessão e outros dados de um usuário para um aplicativo da Web vulnerável por HTTP, fazendo com que o aplicativo acredite que as solicitações são legítimas.

Diretrizes:

  • Esse é um problema do navegador, não do produto de API. É possível resolver essa vulnerabilidade com o OpenID Connect, o OAuth e outras técnicas.
  • Considere usar técnicas de HMAC, estado, hash, nonce ou PKCE para evitar ataques de falsificação e repetição.

A10:2013 - Redirecionamentos e encaminhamentos não validados

Se um aplicativo da Web realiza redirecionamentos, mas não valida se eles estão enviando usuários para sites confiáveis, os invasores podem enviar usuários para destinos maliciosos para realizar phishing, execução de malware e outros ataques.

Diretrizes:

  • Use o OAuth e aplique a validação em cada solicitação.
  • Evite redirecionamentos 302 inesperados verificando os códigos de resposta na lógica do proxy da API e processando os redirecionamentos de maneira adequada.