10 principais ameaças ao aplicativo da Web

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

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

Visão geral

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

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, 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.

Com a Apigee, a camada de proxy de API pode detectar, bloquear e informar solicitações de API malformadas do cliente antes que elas sejam processadas nos sistemas de back-end. Isso reduz os riscos e protege seus serviços. Solicitações malformadas podem incluir qualquer componente que componha o protocolo HTTP em nível de aplicativo:

  • URL
  • Cabeçalhos
  • Caminho
  • Payload

Solicitações de API malformadas podem ser de clientes conhecidos ou desconhecidos desenvolvidos por desenvolvedores externos, desenvolvedores internos ou bots maliciosos. Esses tipos de solicitações representam a maioria das ameaças 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 resolver as principais vulnerabilidades de segurança da API OWASP sem problemas à medida que você adota uma abordagem focada no consumo para projetar suas APIs e conectá-las aos seus sistemas de back-end. Veja a seguir uma lista de políticas/configurações recomendadas pela Apigee para as principais ameaças REST OWASP.

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

Quando se trata de criar e proteger aplicativos da Web, há muitas preocupações com segurança. O OWASP lançou a lista das 10 principais ameaças de segurança do OWASP de 2017 (em inglês) para aplicativos da Web. Embora um aplicativo da Web tenha muitas partes, a maioria dos apps modernos da Web 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 ela pode desempenhar um papel essencial na proteção das APIs REST. Veja a seguir as principais ameaças de segurança do OWASP com descrições de como é possível usar a Apigee para ajudar a lidar com essas ameaças.

A1:2017 - Injeção

Para se proteger contra injeção de dados não confiáveis, como SQL, NoSQL, LDAP e JavaScript, que pode resultar na execução de comandos não intencionais ou 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 à expectativa antes de permitir mais 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 a transforme 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 - Falha na autenticação e no gerenciamento de sessão

Os invasores podem acessar senhas, tokens de sessão e chaves para falsificar a identidade de outros usuários ao aproveitar as falhas de implementação nos aplicativos. Isso é mais um problema de implementação e não de produto. A Apigee oferece políticas VerifyApiKey, OAuth e JSON Web Token (JWT), que ajudam na proteção contra essa vulnerabilidade.

Validação de chave de API

A validação de chaves de API é a forma mais simples de segurança baseada em app que pode ser configurada para uma API. Um app cliente simplesmente apresenta uma chave de API com a solicitação. Em seguida, o Apigee Edge, por uma política anexada a um proxy de API, verifica se a chave de API está em 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 uma chave secreta quando um app do desenvolvedor é criado e aprovado e vinculado a um ou mais produtos de API.

Às vezes, o termo "chaves de API" pode ter significados diferentes. Na Apigee, quando a relação entre o app e o produto é formada, a Apigee gera um ID e uma chave secreta do cliente. Alguns se referem ao ID e ao secret como a chave de API. Algumas se referem apenas ao ID do cliente como a chave de API. Na interface do Edge, você vai ver "chave do cliente" e "chave secreta do cliente".

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

A Apigee também permite a importação de chaves de API atuais de fontes externas.

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

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 em nome do proprietário de um 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 consiga acesso em seu próprio nome.

As políticas do OAuth 2.0 da Apigee permitem que você implemente e personalize 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 do OAuthv2. O consumidor precisa estar registrado e ter um app aprovado que conceda acesso à API. Em troca, ele receberá um ID e uma chave secreta 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 JWT, geralmente são usados 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 assinaturas HS256 e RS256)
  • Validar tokens JWT
  • Decodificar tokens JWT sem validar

A3:2017 - Exposição a dados confidenciais

Os invasores visam dados confidenciais, como detalhes de cartão de crédito, CPF ou CNPJ, credenciais de login, informações de identificação pessoal (PII) e CPF/CNPJ, 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 dos dados sensíveis.

O TLS (Transport Layer Security, cujo antecessor é 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 aplicativo. A Apigee oferece suporte a TLS unidirecional e bidirecional.

O TLS (cliente que se conecta à API que atua 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 uso de uma configuração de Servidor de destino é compatível com o TLS sul-americano (apigee como um cliente conectado ao serviço de back-end) por meio do uso de uma configuração. Um servidor de destino pode ser configurado para TLS unidirecional ou bidirecional.

A Apigee oferece suporte a várias opções de configuração de TLS.

A aplicação do TLS bidirecional garante que o cliente esteja usando um certificado que já foi integrado à Apigee. O OWASP também fornece 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.

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

  • Use uma plataforma que ofereça suporte a TLS unidirecional e bidirecional, que protegerá o nível do protocolo.
  • Use políticas como a políticaAssignMessage e a política de JavaScript para remover dados sensíveis antes que eles sejam retornados ao cliente.
  • Use as técnicas padrão do OAuth e adicione HMAC, hash, estado, valor de uso único, PKCE ou outras técnicas para melhorar o nível de autenticação de cada solicitação.
  • Use configurações de mascaramento de dados para mascarar dados confidenciais na ferramenta Edge Trace.
  • Tenha cuidado ao armazenar dados confidenciais no cache (ou criptografar dados confidenciais armazenados em cache). No Edge, é possível criptografar dados sensíveis em repouso nos mapas de chave-valor.

A4:2017 - Entidades externas em XML

Sistemas ou aplicativos que processam XML precisam processar "referências de entidades externas" em XML, 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 iniciar 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 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. Essa política aplica um padrão de texto ao conteúdo da mensagem e, ao encontrar uma correspondência, define uma variável com o conteúdo especificado da mensagem.

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 têm acesso a um sistema, controles de autorização adequados precisam estar em vigor para que os usuários possam ver e fazer apenas o que têm permissão. Sem controles de acesso fortes, os invasores podem visualizar dados não autorizados e geralmente confidenciais ou manipular de maneira maliciosa dados e o comportamento do sistema.

A Apigee oferece suporte a uma abordagem em camadas para implementar controles de acesso e evitar que usuários de má-fé 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, na sigla em inglês) para permitir que os usuários acessem apenas a funcionalidade e a configuração de que precisam em portais de desenvolvedores baseados em Drupal.
  • Configure portais de desenvolvedores para mostrar produtos de API específicos de acordo com a função do usuário.
  • Configure o portal para mostrar ou ocultar conteúdo com base na função do usuário.

Controles de acesso para acessar as APIs do ambiente de execução da Apigee

  • O acesso às APIs pode ser aplicado com chaves de API, tokens OAuth, escopos OAuth, certificados e outras técnicas.
  • O provedor da API configura quais recursos estão disponíveis definindo um produto de API. O acesso é concedido manualmente na interface, pela API de gerenciamento ou pelo portal do desenvolvedor. Quando o app de um desenvolvedor recebe acesso a um produto da API, ele recebe um ID do cliente e uma chave secreta 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 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

Configurações incorretas de segurança são fáceis de ignorar, geralmente porque administradores e desenvolvedores confiam erroneamente que os sistemas usados são inerentemente seguros. Configurações incorretas de segurança podem ocorrer de várias maneiras diferentes, como confiar nas configurações padrão ou definir configurações parciais que podem não ser seguras, permitir que mensagens de erro contenham detalhes confidenciais, armazenar dados na nuvem sem os controles de segurança adequados, configurar cabeçalhos HTTP de maneira incorreta e assim por diante. A plataforma Apigee oferece uma série de mecanismos para permitir o controle, o gerenciamento e o monitoramento de configurações de segurança, incluindo fluxos compartilhados reutilizáveis.

Com um fluxo compartilhado, os desenvolvedores de API podem combinar 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, diminuir o tempo de desenvolvimento e gerenciar o código com mais facilidade. É possível incluir um fluxo compartilhado em proxies de API individuais ou ir além e colocar fluxos compartilhados em 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.

As versões 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 de borda recebe patches automaticamente. Os clientes do Edge para nuvem privada (no local) precisam aplicar os patches de produtos por conta própria.

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

O scripting em vários sites (XSS) permite que invasores executem scripts em navegadores da Web para controlar sessões do usuário, manipular sites ou afetar os usuários de maneira maliciosa 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, seja com a política RegularExpressionProtection ou a política JavaScript, verifique os valores de payload e parâmetro em relação a JavaScript e outros ataques do tipo por injeção.

O CORS, uma das soluções com frequência implementadas para a política de mesma origem aplicada por todos os navegadores, pode ser implementado usando a políticaAssignMessage.

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

Os atacantes 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.

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 de JavaScript também pode ser usada para verificar a presença de conteúdo malicioso nos payloads. O cache e outras políticas podem ser usados para proteção contra ataques de repetição. No nível da infraestrutura, a plataforma da Apigee também tem proteções integradas para proteger os 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.

As versões regulares de produtos da Apigee garantem proteção contra vulnerabilidades de componentes, especialmente quando vulnerabilidades específicas são descobertas. A nuvem pública da Apigee é corrigida automaticamente, e a Apigee notifica o Edge para clientes da 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 executa adequadamente a geração de registros, o monitoramento e o gerenciamento de incidentes nos sistemas, os invasores podem realizar ataques mais profundos e prolongados nos dados e no software.

A Apigee tem várias maneiras de executar registros, monitoramento, tratamento de erros e registros de auditoria.

Geração de registros

  • As mensagens de registro podem ser enviadas para o Splunk ou outro endpoint syslog usando a política MessageLogging.
  • Os dados de análise de APIs podem ser extraídos por meio da API Analytics e importados ou exportados para outros sistemas.
  • No Edge para nuvem privada, é possível usar a política MessageLogging para gravar arquivos de registros locais. 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 REST de maneira síncrona ou assíncrona.

Monitoramento

Tratamento de erros

A Apigee oferece um mecanismo de tratamento de falhas poderoso e versátil para proxies de API. Da mesma forma que um programa Java captura exceções, os proxies de API podem detectar falhas e determinar como retornar respostas apropriadas aos clientes. O tratamento de falhas personalizado da Apigee permite adicionar funcionalidades, como geração de registros de mensagens, sempre que um erro ocorre.

Registros de auditoria

A plataforma Apigee mantém um registro de auditoria que rastreia 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 Apigee para vulnerabilidades do OWASP em 2013

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

A8:2013 - Falsificação de solicitação entre sites (CSRF, na sigla em inglês)

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, induzindo o aplicativo da Web a acreditar que as solicitações são legítimas.

Diretrizes:

  • Isso se trata mais de um problema do navegador, não de um problema com o produto da API. É possível solucionar essa vulnerabilidade com o OpenID Connect, o OAuth e outras técnicas.
  • Considere o uso de técnicas HMAC, estado, hash, valor de uso único ou PKCE para evitar ataques de falsificação e repetição.

A10:2013 - Redirecionamentos e encaminhamentos não validados

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

Diretrizes:

  • Usar o OAuth e aplicar 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 corretamente.