Recomendações para mitigar as 10 principais ameaças de segurança da API OWASP usando o Gerenciamento de API

  • Artigo

APLICA-SE A: Todas as camadas de gerenciamento de API

A Open Web Application Security Project (OWASP) Foundation trabalha para melhorar a segurança do software através de seus projetos de software de código aberto liderados pela comunidade, centenas de capítulos em todo o mundo, dezenas de milhares de membros e sediando conferências locais e globais.

O Projeto de Segurança da API OWASP concentra-se em estratégias e soluções para entender e mitigar as vulnerabilidades e riscos de segurança exclusivos das APIs. Neste artigo, discutiremos recomendações para usar o Gerenciamento de API do Azure para mitigar as 10 principais ameaças de API identificadas pelo OWASP.

Nota

Além de seguir as recomendações neste artigo, você pode habilitar o Defender for APIs, um recurso do Microsoft Defender for Cloud, para insights de segurança de API, recomendações e deteção de ameaças. Saiba mais sobre como usar o Defender for APIs com o Gerenciamento de API

Autorização de nível de objeto quebrado

Os objetos de API que não estão protegidos com o nível apropriado de autorização podem estar vulneráveis a vazamentos de dados e manipulação não autorizada de dados por meio de identificadores fracos de acesso a objetos. Por exemplo, um invasor pode explorar um identificador de objeto inteiro, que pode ser iterado.

Mais informações sobre esta ameaça: API1:2019 Broken Object Level Authorization

Recomendações

  • O melhor lugar para implementar a autorização no nível do objeto é dentro da própria API de back-end. No back-end, as decisões corretas de autorização podem ser tomadas no nível da solicitação (ou objeto), quando aplicável, usando a lógica aplicável ao domínio e à API. Considere cenários em que uma determinada solicitação pode produzir diferentes níveis de detalhe na resposta, dependendo das permissões e autorização do solicitante.

  • Se uma API vulnerável atual não puder ser alterada no back-end, o Gerenciamento de API poderá ser usado como um fallback. Por exemplo:

    • Use uma política personalizada para implementar a autorização no nível do objeto, se ela não for implementada no back-end.

    • Implemente uma política personalizada para mapear identificadores de solicitação para back-end e de back-end para cliente, para que os identificadores internos não sejam expostos.

      Nesses casos, a política personalizada pode ser uma expressão de política com uma pesquisa (por exemplo, um dicionário) ou integração com outro serviço por meio da política de solicitação de envio.

  • Para cenários do GraphQL, imponha a autorização no nível do objeto por meio da política de solicitação Validate GraphQL, usando o authorize elemento .

Autenticação de usuário quebrada

Os mecanismos de autenticação geralmente são implementados incorretamente ou ausentes, permitindo que os invasores explorem falhas de implementação para acessar dados.

Mais informações sobre esta ameaça: API2:2019 Broken User Authentication

Recomendações

Use o Gerenciamento de API para autenticação e autorização do usuário:

  • Autenticação - O Gerenciamento de API suporta os seguintes métodos de autenticação:

    • Política de autenticação básica - Credenciais de nome de usuário e senha.

    • Chave de subscrição - Uma chave de subscrição fornece um nível de segurança semelhante ao da autenticação básica e pode não ser suficiente por si só. Se a chave de subscrição estiver comprometida, um intruso poderá obter acesso ilimitado ao sistema.

    • Política de certificado de cliente - Usar certificados de cliente é mais seguro do que credenciais básicas ou chave de assinatura, mas não permite a flexibilidade fornecida por protocolos de autorização baseados em token, como OAuth 2.0.

  • Autorização - O Gerenciamento de API suporta uma política JWT de validação para verificar a validade de um token de acesso JWT OAuth 2.0 de entrada com base em informações obtidas do ponto de extremidade de metadados do provedor de identidade OAuth. Configure a política para verificar as declarações de token, o público e o tempo de expiração relevantes. Saiba mais sobre como proteger uma API usando a autorização OAuth 2.0 e o Microsoft Entra ID.

Mais recomendações:

  • Use políticas no Gerenciamento de API para aumentar a segurança. Por exemplo, a limitação da taxa de chamadas diminui a velocidade dos agentes mal-intencionados usando ataques de força bruta para comprometer credenciais.

  • As APIs devem usar TLS/SSL (segurança de transporte) para proteger as credenciais ou tokens. Credenciais e tokens devem ser enviados em cabeçalhos de solicitação e não como parâmetros de consulta.

  • No portal do desenvolvedor do Gerenciamento de API, configure o Microsoft Entra ID ou o Azure Ative Directory B2C como o provedor de identidade para aumentar a segurança da conta. O portal do desenvolvedor usa CAPTCHA para mitigar ataques de força bruta.

Exposição excessiva de dados

Um bom design de interface API é enganosamente desafiador. Muitas vezes, particularmente com APIs herdadas que evoluíram ao longo do tempo, as interfaces de solicitação e resposta contêm mais campos de dados do que os aplicativos de consumo exigem.

Um agente mal-intencionado pode tentar acessar a API diretamente (talvez reproduzindo uma solicitação válida) ou detetar o tráfego entre o servidor e a API. A análise das ações da API e dos dados disponíveis pode gerar dados confidenciais para o invasor, que não são apresentados ou usados pelo aplicativo frontend.

Mais informações sobre esta ameaça: API3:2019 Exposição excessiva de dados

Recomendações

  • A melhor abordagem para mitigar essa vulnerabilidade é garantir que as interfaces externas definidas na API de back-end sejam projetadas cuidadosamente e, idealmente, independentemente da persistência de dados. Eles devem conter apenas os campos exigidos pelos consumidores da API. As APIs devem ser revisadas com freqüência e os campos herdados preteridos e, em seguida, removidos.

    No Gerenciamento de API, use:

    • Revisões para controlar graciosamente alterações ininterruptas, por exemplo, a adição de um campo a uma interface. Você pode usar revisões junto com uma implementação de controle de versão no back-end.

    • Versões para quebrar alterações, por exemplo, a remoção de um campo de uma interface.

  • Se não for possível alterar o design da interface de back-end e o excesso de dados for uma preocupação, use as políticas de transformação do Gerenciamento de API para reescrever as cargas úteis de resposta e mascarar ou filtrar dados. Por exemplo, remova propriedades JSON desnecessárias de um corpo de resposta.

  • A validação de conteúdo de resposta no Gerenciamento de API pode ser usada com um esquema XML ou JSON para bloquear respostas com propriedades não documentadas ou valores impróprios. A política também suporta o bloqueio de respostas que excedam um tamanho especificado.

  • Use a política de código de status de validação para bloquear respostas com erros indefinidos no esquema da API.

  • Use a política de validação de cabeçalhos para bloquear respostas com cabeçalhos que não estão definidos no esquema ou não estão em conformidade com sua definição no esquema. Remova cabeçalhos indesejados com a política de cabeçalho definida.

  • Para cenários do GraphQL, use a política de solicitação do GraphQL para validar solicitações do GraphQL, autorizar o acesso a caminhos de consulta específicos e limitar o tamanho da resposta.

Falta de recursos e limitação de taxas

A falta de limitação de taxa pode levar à exfiltração de dados ou ataques DDoS bem-sucedidos em serviços de back-end, causando uma interrupção para todos os consumidores.

Mais informações sobre esta ameaça: API4:2019 Falta de recursos e limitação de taxas

Recomendações

  • Use políticas de limite de taxa (curto prazo) e limite de cota (longo prazo) para controlar o número permitido de chamadas de API ou largura de banda por consumidor.

  • Defina definições estritas de objeto de solicitação e suas propriedades na definição OpenAPI. Por exemplo, defina o valor máximo para inteiros de paginação, maxLength e expressão regular (regex) para cadeias de caracteres. Imponha esses esquemas com as políticas de validação de conteúdo e parâmetros no Gerenciamento de API.

  • Imponha o tamanho máximo da solicitação com a política de conteúdo validada.

  • Otimize o desempenho com cache integrado, reduzindo assim o consumo de CPU, memória e recursos de rede para determinadas operações.

  • Imponha a autenticação para chamadas de API (consulte Autenticação de usuário quebrada). Revogue o acesso para usuários abusivos. Por exemplo, desative a chave de assinatura, bloqueie o endereço IP com a política de IPs de chamador restrito ou rejeite solicitações para uma determinada declaração de usuário de um token JWT.

  • Aplique uma política CORS para controlar os sites que têm permissão para carregar os recursos servidos por meio da API. Para evitar configurações excessivamente permissivas, não use valores curinga (*) na política CORS.

  • Minimize o tempo que um serviço de back-end leva para responder. Quanto mais tempo o serviço de back-end demorar para responder, mais tempo a conexão estará ocupada no Gerenciamento de API, reduzindo assim o número de solicitações que podem ser atendidas em um determinado período de tempo.

  • Embora o Gerenciamento de API possa proteger os serviços de back-end contra ataques DDoS, ele pode ser vulnerável a esses próprios ataques. Implante um serviço de proteção de bot na frente do Gerenciamento de API (por exemplo, Azure Application Gateway, Azure Front Door ou Proteção contra DDoS do Azure) para proteger melhor contra ataques DDoS. Ao usar um WAF com o Gateway de Aplicativo do Azure ou o Azure Front Door, considere usar o Microsoft_BotManagerRuleSet_1.0.

Autorização de nível de função quebrado

Políticas complexas de controle de acesso com hierarquias, grupos e funções diferentes e uma separação pouco clara entre funções administrativas e regulares levam a falhas de autorização. Ao explorar esses problemas, os invasores obtêm acesso aos recursos ou funções administrativas de outros usuários.

Mais informações sobre esta ameaça: API5:2019 Autorização de nível de função quebrada

Recomendações

  • Por padrão, proteja todos os pontos de extremidade da API no Gerenciamento de API com chaves de assinatura.

  • Defina uma política JWT de validação e imponha as declarações de token necessárias. Se determinadas operações exigirem uma aplicação de declarações mais rigorosa, defina políticas adicionais validate-jwt apenas para essas operações.

  • Use uma rede virtual do Azure ou um Link Privado para ocultar pontos de extremidade de API da Internet. Saiba mais sobre as opções de rede virtual com o Gerenciamento de API.

  • Não defina operações de API curinga (ou seja, APIs "catch-all" com * como caminho). Certifique-se de que o Gerenciamento de API atenda apenas solicitações de pontos de extremidade explicitamente definidos e que as solicitações para pontos de extremidade indefinidos sejam rejeitadas.

  • Não publique APIs com produtos abertos que não exijam uma assinatura.

Atribuição em massa

Se uma API oferecer mais campos do que o cliente requer para uma determinada ação, um invasor pode injetar propriedades excessivas para executar operações não autorizadas em dados. Os invasores podem descobrir propriedades não documentadas inspecionando o formato de solicitações e respostas ou outras APIs, ou adivinhando-as. Esta vulnerabilidade é especialmente aplicável se você não usar linguagens de programação fortemente tipadas.

Mais informações sobre esta ameaça: API6:2019 Atribuição em massa

Recomendações

  • As interfaces API externas devem ser dissociadas da implementação de dados internos. Evite vincular contratos de API diretamente a contratos de dados em serviços de back-end. Revise o design da API com freqüência e deprecie e remova propriedades herdadas usando o controle de versão no Gerenciamento de API.

  • Defina com precisão contratos XML e JSON no esquema de API e use validar conteúdo e validar políticas de parâmetros para bloquear solicitações e respostas com propriedades não documentadas. O bloqueio de solicitações com propriedades não documentadas atenua os ataques, enquanto o bloqueio de respostas com propriedades não documentadas dificulta a engenharia reversa de potenciais vetores de ataque.

  • Se a interface de back-end não puder ser alterada, use políticas de transformação para reescrever cargas úteis de solicitação e resposta e separar os contratos de API dos contratos de back-end. Por exemplo, mascare ou filtre dados ou remova propriedades JSON desnecessárias.

Configuração incorreta de segurança

Os atacantes podem tentar explorar vulnerabilidades de configuração incorreta de segurança, tais como:

  • Falta de proteção de segurança
  • Recursos ativados desnecessários
  • Ligações de rede desnecessariamente abertas à Internet
  • Uso de protocolos fracos ou cifras
  • Outras configurações ou pontos de extremidade que podem permitir acesso não autorizado ao sistema

Mais informações sobre esta ameaça: API7:2019 Configuração incorreta de segurança

Recomendações

  • Configure corretamente o TLS do gateway. Não use protocolos vulneráveis (por exemplo, TLS 1.0, 1.1) ou cifras.

  • Configure APIs para aceitar apenas tráfego criptografado, por exemplo, por meio de protocolos HTTPS ou WSS.

  • Considere implantar o Gerenciamento de API atrás de um ponto de extremidade privado ou conectado a uma rede virtual implantada no modo interno. Nas redes internas, o acesso pode ser controlado a partir da rede privada (através de firewall ou grupos de segurança de rede) e da Internet (através de um proxy reverso).

  • Use as políticas de Gerenciamento de API do Azure:

    • Sempre herde políticas pai por meio da <base> tag .

    • Ao usar o OAuth 2.0, configure e teste a política JWT validada para verificar a existência e a validade do token JWT antes que ele chegue ao back-end. Verifique automaticamente o tempo de expiração do token, a assinatura do token e o emissor. Imponha declarações, audiências, expiração de token e assinatura de token por meio de configurações de política.

    • Configure a política CORS e não use curinga * para nenhuma opção de configuração. Em vez disso, liste explicitamente os valores permitidos.

    • Defina políticas de validação em prevent ambientes de produção para validar esquemas JSON e XML, cabeçalhos, parâmetros de consulta e códigos de status e para impor o tamanho máximo de solicitação ou resposta.

    • Se o Gerenciamento de API estiver fora de um limite de rede, a validação de IP do cliente ainda será possível usando a política de IPs restritos do chamador. Certifique-se de que ele usa uma lista de permissões, não uma lista de bloqueio.

    • Se os certificados de cliente forem usados entre o chamador e o Gerenciamento de API, use a política de certificado de cliente para validar. Certifique-se de que os validate-revocationatributos , validate-trust, validate-not-beforee estão validate-not-after todos definidos como true.

      • Os certificados de cliente (TLS mútuo) também podem ser aplicados entre o Gerenciamento de API e o back-end. O back-end deve:

        • Ter credenciais de autorização configuradas

        • Validar a cadeia de certificados, quando aplicável

        • Validar o nome do certificado, quando aplicável

  • Para cenários do GraphQL, use a política de solicitação do GraphQL para validação. Certifique-se de que o elemento e max-sizemax-depth os authorization atributos estão definidos.

  • Não armazene segredos em arquivos de política ou no controle do código-fonte. Sempre use valores nomeados do Gerenciamento de API ou busque os segredos em tempo de execução usando expressões de política personalizadas.

    • Os valores nomeados devem ser integrados ao Cofre de Chaves ou criptografados no Gerenciamento de API, marcando-os como "secretos". Nunca armazene segredos em valores nomeados em texto simples.

  • Publique APIs por meio de produtos, que exigem assinaturas. Não use produtos abertos que não exijam uma assinatura.

  • Use a integração do Key Vault para gerenciar todos os certificados – isso centraliza o gerenciamento de certificados e pode ajudar a facilitar as tarefas de gerenciamento de operações, como renovação ou revogação de certificados.

  • Ao usar o gateway auto-hospedado, certifique-se de que há um processo em vigor para atualizar a imagem para a versão mais recente periodicamente.

  • Representar serviços de back-end como entidades de back-end. Configure credenciais de autorização, validação de cadeia de certificados e validação de nome de certificado, quando aplicável.

  • Ao usar o portal do desenvolvedor:

    • Se você optar por hospedar automaticamente o portal do desenvolvedor, verifique se há um processo em vigor para atualizar periodicamente o portal auto-hospedado para a versão mais recente. As atualizações para a versão gerenciada padrão são automáticas.

    • Use o Microsoft Entra ID ou o Azure Ative Directory B2C para inscrição e entrada de usuários. Desative a autenticação padrão de nome de usuário e senha, que é menos segura.

    • Atribua grupos de usuários a produtos, para controlar a visibilidade das APIs no portal.

  • Use a Política do Azure para impor a configuração no nível de recursos do Gerenciamento de API e permissões de controle de acesso baseado em função (RBAC) para controlar o acesso aos recursos. Conceda privilégios mínimos necessários a todos os usuários.

  • Use um processo de DevOps e uma abordagem de infraestrutura como código fora de um ambiente de desenvolvimento para garantir a consistência do conteúdo do Gerenciamento de API e as alterações de configuração e minimizar os erros humanos.

  • Não use nenhum recurso preterido.

Injeção

Qualquer ponto de extremidade que aceite dados do usuário é potencialmente vulnerável a uma exploração de injeção. Os exemplos incluem, mas não estão limitados a:

  • Injeção de comando, em que um agente mal-intencionado tenta alterar a solicitação da API para executar comandos no sistema operacional que hospeda a API

  • Injeção de SQL, em que um agente mal-intencionado tenta alterar a solicitação de API para executar comandos e consultas no banco de dados do qual uma API depende

Mais informações sobre esta ameaça: API8:2019 Injection

Recomendações

  • As políticas modernas do WAF (Web Application Firewall) cobrem muitas vulnerabilidades comuns de injeção. Embora o Gerenciamento de API não tenha um componente WAF interno, a implantação de um WAF upstream (na frente) da instância de Gerenciamento de API é altamente recomendada. Por exemplo, use o Azure Application Gateway ou o Azure Front Door.

    Importante

    Certifique-se de que um agente mal-intencionado não possa ignorar o gateway que hospeda o WAF e conectar-se diretamente ao gateway de Gerenciamento de API ou à própria API de back-end. As possíveis atenuações incluem: ACLs de rede, usando a política de Gerenciamento de API para restringir o tráfego de entrada por IP do cliente, removendo o acesso público onde não é necessário e autenticação de certificado de cliente (também conhecida como TLS mútuo ou mTLS).

  • Use políticas de validação de esquema e parâmetros, quando aplicável, para restringir e validar ainda mais a solicitação antes que ela chegue ao serviço de API de back-end.

    O esquema fornecido com a definição da API deve ter uma restrição de padrão regex aplicada a campos vulneráveis. Cada regex deve ser testado para garantir que restringe o campo o suficiente para mitigar as tentativas comuns de injeção.

Gestão inadequada de ativos

As vulnerabilidades relacionadas com a gestão inadequada de ativos incluem:

  • Falta de documentação adequada da API ou informações de propriedade

  • Números excessivos de versões mais antigas da API, que podem estar faltando correções de segurança

Mais informações sobre esta ameaça: API9:2019 Gestão imprópria de ativos

Recomendações

  • Use uma especificação OpenAPI bem definida como fonte para importar APIs REST. A especificação permite o encapsulamento da definição da API, incluindo metadados de autodocumentação.

    • Use interfaces de API com caminhos precisos, esquemas de dados, cabeçalhos, parâmetros de consulta e códigos de status. Evite operações curinga. Forneça descrições para cada API e operação e inclua informações de contato e licença.

    • Evite endpoints que não contribuam diretamente para o objetivo comercial. Eles aumentam desnecessariamente a área da superfície de ataque e dificultam a evolução da API.

  • Use revisões e versões no Gerenciamento de API para governar e controlar os pontos de extremidade da API. Tenha uma forte estratégia de controle de versão de back-end e comprometa-se com um número máximo de versões de API suportadas (por exemplo, 2 ou 3 versões anteriores). Planeje depreciar rapidamente e, finalmente, remover versões de API mais antigas, muitas vezes menos seguras.

  • Use uma instância de Gerenciamento de API por ambiente (como desenvolvimento, teste e produção). Certifique-se de que cada instância de Gerenciamento de API se conecte às suas dependências no mesmo ambiente. Por exemplo, no ambiente de teste, o recurso de Gerenciamento de API de teste deve se conectar a um recurso de teste do Cofre de Chaves do Azure e às versões de teste dos serviços de back-end. Use a automação de DevOps e as práticas de infraestrutura como código para ajudar a manter a consistência e a precisão entre ambientes e reduzir erros humanos.

  • Use tags para organizar APIs e produtos e agrupá-los para publicação.

  • Publique APIs para consumo por meio do portal do desenvolvedor integrado. Verifique se a documentação da API está atualizada.

  • Descubra APIs não documentadas ou não gerenciadas e as exponha por meio do Gerenciamento de API para um melhor controle.

Registo e monitorização insuficientes

O registro e o monitoramento insuficientes, juntamente com a integração ausente ou ineficaz com a resposta a incidentes, permitem que os invasores ataquem ainda mais os sistemas, mantenham a persistência, girem para mais sistemas para adulterar e extraiam ou destruam dados. A maioria dos estudos de violação demonstra que o tempo para detetar uma violação é superior a 200 dias, normalmente detetado por partes externas em vez de processos internos ou monitoramento.

Mais informações sobre esta ameaça: API10:2019 Registo e monitorização insuficientes

Recomendações

  • Entenda as opções de observabilidade no Gerenciamento de API do Azure e as práticas recomendadas para monitoramento no Azure.

  • Monitore o tráfego da API com o Azure Monitor.

  • Faça login no Application Insights para fins de depuração. Correlacione transações no Application Insights entre o Gerenciamento de API e a API de back-end para rastreá-las de ponta a ponta.

  • Se necessário, encaminhe eventos personalizados para Hubs de Eventos.

  • Defina alertas no Azure Monitor e no Application Insights - por exemplo, para a métrica de capacidade ou para solicitações excessivas ou transferência de largura de banda.

  • Use a política de métrica de emissão para métricas personalizadas.

  • Use o log de atividades do Azure para controlar a atividade no serviço.

  • Use eventos personalizados no Azure Application Insights e no Azure Monitor conforme necessário.

  • Configure o OpenTelemetry para gateways auto-hospedados no Kubernetes.

Próximos passos

Saiba mais sobre: