10 principais ameaças ao aplicativo da Web

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

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

Visão geral

Os ecossistemas de API sofrem vários ataques de clientes externos e internos. Oferecer e usar APIs cria grandes oportunidades para 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.

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 de API da OWASP, a organização publica os riscos de segurança mais críticos para aplicativos da Web e APIs REST e fornece recomendações para resolver esses riscos.

Com a Apigee, a camada de proxy de API pode detectar, bloquear e informar solicitações de API malformadas do cliente antes que as solicitações sejam processadas nos sistemas de back-end, mitigando o risco e protegendo seus serviços. Solicitações malformadas podem incluir qualquer componente que compõe o protocolo HTTP no nível do aplicativo:

  • URL
  • Cabeçalhos
  • Caminho
  • Payload

Solicitações de API malformadas podem ser de clientes conhecidos ou desconhecidos desenvolvidos por desenvolvedores externos, internos ou bots maliciosos. Esses tipos de solicitações compõem a maioria das ameaças da OWASP , mas há outros componentes da camada de proxy de API subjacente que podem mitigar riscos, como mascaramento de dados, geração de registros, 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 da OWASP de maneira integrada ao adotar uma abordagem focada no consumo para projetar suas APIs e conectá-las aos sistemas de back-end. A seguir, há uma lista de políticas/configurações que a Apigee recomenda para as principais ameaças REST da OWASP.

Soluções da Apigee para as 10 principais vulnerabilidades 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 de 2017 para aplicativos da Web. Embora um aplicativo da Web tenha muitas partes, a maioria dos aplicativos da Web modernos depende muito de APIs REST. A Apigee não foi criada para atender a todas as necessidades de segurança de um aplicativo da Web, mas pode desempenhar um papel fundamental na proteção das APIs REST. A seguir, estão as principais ameaças de segurança da OWASP com descrições de como você pode usar a Apigee para ajudar a resolver essas ameaças.

A1:2017: injeção

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

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 é mais um problema de implementação e não um problema 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 aplicativo cliente simplesmente apresenta uma chave de API com a solicitação e, em seguida, a 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 à geração e validação de chaves de API. A Apigee gera uma chave de API e um secret quando um app de desenvolvedor é criado e aprovado, 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, a Apigee 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ê verá "token do cliente" e "secret do consumidor."

Na política VerifyAPIKey, apenas o ID do cliente, ou "token do cliente", é verificado. Os desenvolvedores recebem um token do cliente quando eles registram o app na Apigee e associam o app a um produto de API. Os desenvolvedores incluem o token do cliente nas 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 existentes de fontes externas.

Para tipos de permissão de acesso OAuth, o ID e o secret do cliente são usados.

OAuth 2.0

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

As políticas OAuth 2.0 da Apigee permitem implementar e personalizar os quatro tipos de concessão do OAuth 2.0. A aplicação do token de acesso 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 um secret do cliente da API. O consumidor precisa passar por uma das concessõ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

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

  • Gerar tokens JWT (suporta assinatura HS256 e RS256)
  • Validar tokens JWT
  • Decodificar tokens JWT sem validar

A3:2017: exposição de dados sensíveis

Os invasores visam dados sensíveis, como detalhes do cartão, números de CPF ou CNPJ, credenciais de login, informações de identificação pessoal (PII) e números de identificação fiscal para cometer roubo de identidade, roubo de dinheiro, fraude e outros crimes. Os aplicativos da Web precisam implementar criptografia, em repouso e 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 saída (cliente que se conecta à API atuando como servidor) é compatível com o uso de uma configuração de host virtual. Um host virtual pode ser configurado para TLS unidirecional ou bidirecional.

O TLS de entrada (Apigee como um cliente que se conecta 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 de TLS .

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

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

A seguir, há diretrizes para proteger dados sensíveis:

  • Use uma plataforma que ofereça suporte a TLS unidirecional e bidirecional, que vai proteger 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 mascarar dados sensíveis na ferramenta Edge Trace.
  • Tenha cuidado ao armazenar dados sensíveis no cache ou criptografe os dados sensíveis que estão armazenados no cache. No Edge, é possível criptografar dados sensíveis em repouso em mapas de chave-valor.

A4:2017: entidades XML externas

Sistemas ou aplicativos que processam XML precisam lidar com "referências de entidades externas" em XML, referências a arquivos ou dados que são substituídos pelos dados reais durante o processamento de 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 ao 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 atribuí-lo 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, definindo 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. Ele 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 acessam um sistema, os controles de autorização adequados precisam estar em vigor para que os usuários possam ver e fazer apenas o que é permitido. Sem controles de acesso fortes, os invasores podem visualizar dados não autorizados e geralmente sensíveis ou manipular dados e comportamento do sistema de maneira maliciosa.

A Apigee oferece suporte a 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 papéis (RBAC) para permitir que os usuários só acessem a funcionalidade e a configuração necessárias nos portais do desenvolvedor 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 acesso à API de ambiente de execução da Apigee

  • O acesso às APIs pode ser aplicado por 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 e um secret do cliente que são usados no processo de autenticação.
  • A Apigee pode se integrar a qualquer provedor de identidade para realizar 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, geralmente porque 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, permitir que mensagens de erro contenham detalhes sensíveis, armazenar dados na nuvem sem controles de segurança adequados, configurar 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 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 um pouco mais longe 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.

Os lançamentos de produtos da Apigee garantem proteção contra bibliotecas com vulnerabilidades. A Apigee pode lançar patches ou atualizações adicionais se novas vulnerabilidades forem encontradas. A nuvem pública do Edge é corrigida automaticamente. Os clientes do Edge para nuvem privada (no local) precisam aplicar os patches do produto.

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 fornece políticas de proteção contra ameaças que podem ser usadas 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 tipos de 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 não segura também pode ativar a execução remota de código execução.

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 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 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: uso de componentes com vulnerabilidades conhecidas

Como frameworks, bibliotecas e módulos são executados com execução completa e acesso CRUD, os invasores podem aproveitar as vulnerabilidades de componentes 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. O Cloud público da Apigee é corrigido automaticamente, e a Apigee notifica os clientes do Edge para nuvem privada quando patches locais estão disponíveis para instalação.

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

Quando você não realiza adequadamente a geração de registros, o monitoramento e o gerenciamento de incidentes 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 por meio da API Analytics e importá-los ou exportá-los para outros sistemas.
  • No Edge para nuvem privada, é possível usar a política MessageLogging para gravar em arquivos de registros locais. Os arquivos de registros 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

  • Use a interface ou a API da API Monitoring para monitorar regularmente APIs e back-ends e acionar alertas.
  • Use health monitoring para monitorar regularmente os back-ends do servidor de destino.
  • A Apigee fornece recomendações para monitorar o Edge para nuvem privada.
  • A Apigee também fornece práticas recomendadas que sua equipe pode aproveitar para monitorar seu programa de API.

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 da OWASP de 2013

Quando a 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 usando a Apigee.

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

As solicitações de falsificação entre sites permitem que os 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, enganando o aplicativo da Web para acreditar que as solicitações são legítimas do usuário.

Diretrizes:

  • Esse é mais um problema de navegador, não um problema de 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 realizar redirecionamentos, mas não validar se os redirecionamentos estão enviando usuários para sites confiáveis e pretendidos, os invasores poderão 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 códigos de resposta na lógica de proxy de API e processando redirecionamentos adequadamente.