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 do Gerenciamento de API

A OWASP (Open Web Application Security Project) Foundation trabalha para melhorar a segurança de software por meio 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 hospeda conferências locais e globais.

O Projeto de Segurança da API OWASP se concentra em estratégias e soluções para entender e mitigar as vulnerabilidades e os 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.

Observação

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

Autorização de nível de objeto danificada

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 de dados não autorizados por meio de identificadores de acesso a objetos fracos. Por exemplo, um invasor pode explorar um identificador de objeto inteiro, que pode ser iterado.

Para obter mais informações sobre esta ameaça: API1:2019 Autorização de nível de objeto danificada

Recomendações

  • O melhor local para implementar a autorização em nível de objeto é dentro da própria API de back-end. No back-end, as decisões de autorização corretas podem ser tomadas no nível de 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 gerar diferentes níveis de detalhes na resposta, dependendo das permissões e da 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 em nível de 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 pesquisa (por exemplo, um dicionário) ou integração com outro serviço por meio da política de enviar solicitação.

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

Autenticação de usuário danificada

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

Para obter mais informações sobre esta ameaça: API2:2019 Autenticação de usuário danificada

Recomendações

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

  • Autenticação – o Gerenciamento de API dá suporte aos seguintes métodos de autenticação:

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

    • Chave de assinatura – uma chave de assinatura fornece um nível de segurança semelhante à autenticação básica e pode não ser suficiente sozinha. Se a chave de assinatura for comprometida, um invasor poderá obter acesso ilimitado ao sistema.

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

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

Mais recomendações:

  • Use políticas no Gerenciamento de API para aumentar a segurança. Por exemplo, a limitação da taxa de chamadas retarda os agentes mal-intencionados que usam ataques de força bruta para comprometer as 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 a ID do Microsoft Entra ou o Azure Active 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 de API é conceitualmente 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 repetindo uma solicitação válida) ou detectar o tráfego entre o servidor e a API. A análise das ações da API e os dados disponíveis podem fornecer dados confidenciais para o invasor, que não são exibidos ou usados ​​pelo aplicativo de front-end.

Para obter 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 com cuidado e, de forma ideal, independentemente da persistência dos dados. Eles devem conter apenas os campos exigidos pelos consumidores da API. As APIs devem ser revisadas com frequência e os campos herdados devem ser preteridos e removidos.

    No Gerenciamento de API, use:

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

    • Versões para alterações interruptivas, 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 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 dá suporte ao bloqueio de respostas que excedem um tamanho especificado.

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

  • Use a política de validar 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 definir cabeçalho.

  • Para cenários do GraphQL, use a política de validar 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 taxa

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.

Para obter mais informações sobre esta ameaça: API4:2019 Falta de recursos e limitação de taxa

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 de 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 validar conteúdo e validar parâmetros no Gerenciamento de API.

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

  • 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 à API (confiraAutenticação de usuário danificada). Revogue o acesso para usuários abusivos. Por exemplo, desative a chave de assinatura, bloqueie o endereço IP com a política de restrição de IPs do chamador 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 necessário para que um serviço de back-end responda. Quanto mais tempo o serviço de back-end demorar para responder, mais tempo a conexão será ocupada no Gerenciamento de API, reduzindo, portanto, 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 de ataques DDoS, ele pode ser vulnerável a esses ataques. Implante um serviço de proteção contra bots na frente do Gerenciamento de API (por exemplo, Gateway de Aplicativo do Azure, Azure Front Door ou Proteção contra DDoS do Azure) para proteger melhor contra ataques DDoS. Ao usar um WAF com Gateway de Aplicativo do Azure ou Azure Front Door, considere usar Microsoft_BotManagerRuleSet_1.0.

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

Políticas de controle de acesso complexas com diferentes hierarquias, grupos e funções 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.

Para obter mais informações sobre esta ameaça: API5:2019 Autorização de nível de função danificada

Recomendações

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

  • Defina uma política de validar JWT 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 validate-jwt extras apenas para essas operações.

  • Use uma rede virtual do Azure ou 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 o caminho). Verifique se o Gerenciamento de API atende apenas a solicitações de pontos de extremidade definidos explicitamente e as solicitações para pontos de extremidade indefinidos são rejeitadas.

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

Atribuição em massa

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

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

Recomendações

  • As interfaces de API externas devem ser desacopladas 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 frequência e suspenda e remova as propriedades herdadas usando o controle de versão no Gerenciamento de API.

  • Defina com precisão contratos XML e JSON no esquema da API e use as políticas de validar conteúdo e validar parâmetros para bloquear solicitações e respostas com propriedades não documentadas. O bloqueio de solicitações com propriedades não documentadas reduz os ataques, enquanto o bloqueio de respostas com propriedades não documentadas dificulta a engenharia reversa de possíveis 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 dissociar os contratos de API dos contratos de back-end. Por exemplo, mascarar ou filtrar dados ou remover propriedades JSON desnecessárias.

Configuração incorreta de segurança

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

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

Para obter 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 criptografias.

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

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

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

    • Sempre herda as políticas pai por meio da marca <base>.

    • Ao usar o OAuth 2.0, configure e teste a política de validar JWT 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. Impor 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 para prevent em 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 para 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 restrição de IPs do chamador. Verifique se ele usa uma lista de permissões, não uma lista de bloqueios.

    • Se os certificados do cliente forem usados entre o chamador e o Gerenciamento de API, use a política de validar certificado do cliente. Verifique se os atributos validate-revocation, validate-trust, validate-not-before e validate-not-after estão 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 graphQL, use a política de validar solicitação do GraphQL . Verifique se o elemento authorization e os atributos max-size e max-depthestã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 Key Vault ou criptografados no Gerenciamento de API, marcando-os como "secretos". Nunca armazene segredos em valores nomeados em texto sem formatação.

  • 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 de certificado ou revogação.

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

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

  • Ao usar o portal do desenvolvedor:

    • Se você optar por auto-hospedar 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 da versão gerenciada padrão são automáticas.

    • Use ID do Microsoft Entra ou Azure Active Directory B2C para inscrição e entrada do usuário. Desabilite o nome de usuário padrão e a autenticação de senha, o que é menos seguro.

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

  • Use o Azure Policy para impor a configuração de nível de recurso de gerenciamento de API e as permissões de controle de acesso baseado em função (RBAC) para controlar o acesso a recursos. Conceda privilégios mínimos necessários a cada usuário.

  • 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 de gerenciamento de API e alterações de configuração e minimizar 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 se limitam 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 da API para executar comandos e consultas no banco de dados do qual uma API depende

Para obter mais informações sobre esta ameaça:API8:2019 Injeção

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 integrado, é altamente recomendável implantar um WAF upstream (na frente) da instância do Gerenciamento de API. Por exemplo, use o Gateway de Aplicativo do Azure ou o Azure Front Door.

    Importante

    Verifique se um agente mal-intencionado não pode ignorar o gateway que hospeda o WAF e se conectar diretamente ao gateway de Gerenciamento de API ou à própria API de back-end. As possíveis mitigações incluem: ACLs de rede, usando a política do Gerenciamento de API para restringir o tráfego de entrada por IP do cliente, removendo o acesso público onde não for 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âmetro, 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 de API deve ter uma restrição de padrão regex aplicada a campos vulneráveis. Cada regex deve ser testado para garantir que ele restrinja o campo o suficiente para atenuar as tentativas comuns de injeção.

Gerenciamento de ativos inadequados

As vulnerabilidades relacionadas ao gerenciamento de ativos inadequados incluem:

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

  • Número excessivo de versões de API mais antigas, que pode consistir em correções de segurança faltantes

Para obter mais informações sobre esta ameaça: API9:2019 Gerenciamento de ativos inadequados

Recomendações

  • Use uma especificação OpenAPI bem definida como origem para importar APIs REST. A especificação permite o encapsulamento da definição de API, incluindo metadados de auto-documentaçã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 pontos de extremidade que não contribuam diretamente para o objetivo de negócios. 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 estratégia de versão de back-end forte e comprometa-se com um número máximo de versões de API compatíveis (por exemplo, 2 ou 3 versões anteriores). Planeje substituir rapidamente e, em última análise, remover versões de API mais antigas, geralmente menos seguras.

  • Use uma instância de gerenciamento de API por ambiente (como desenvolvimento, teste e produção). Verifique se cada instância de Gerenciamento de API se conecta às suas dependências no mesmo ambiente. Por exemplo, no ambiente de teste, o recurso do Gerenciamento de API de teste deve se conectar a um recurso de teste do Azure Key Vault 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 os ambientes e reduzir os erros humanos.

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

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

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

Registro em log e monitoramento insuficientes

O registro em log e o monitoramento insuficientes, juntamente com a integração ausente ou ineficaz com a resposta a incidentes, permite que os invasores ataquem mais sistemas, mantenham a persistência, dinamizem para mais sistemas a serem adulterados e extraiam ou destruam dados. A maioria dos estudos de violação demonstram que o tempo para detectar uma violação é de mais de 200 dias, normalmente detectado por partes externas em vez de processos internos ou monitoramento.

Para obter mais informações sobre esta ameaça: API10:2019 Registro e monitoramento insuficientes

Recomendações

Próximas etapas

Saiba mais sobre: