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

Observação

Este artigo foi atualizado para refletir a lista mais recente das 10 principais seguranças de API da OWASP para 2023.

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 as recomendações mais recentes para atenuar as 10 principais ameaças de API identificadas pelo OWASP em sua lista de 2023 usando o Gerenciamento de API do Azure.

Embora o Gerenciamento de API forneça controles abrangentes para a segurança da API, outros serviços da Microsoft fornecem funcionalidade complementar para detectar ou proteger contra ameaças à API OWASP:

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:2023 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 validate-graphql-request, usando o elemento authorize.

Autenticação danificada

O mecanismo de autenticação de um site ou API é especialmente vulnerável porque está aberto a usuários anônimos. Os ativos e pontos de extremidade necessários para autenticação, incluindo senha esquecida ou redefinição de fluxos de senha, devem ser protegidos para evitar a exploração.

Para obter mais informações sobre esta ameaça: API2:2023 Autenticação danificada

Recomendações

  • Use o Microsoft Entra para implementar a autenticação de API. O Microsoft Entra fornece automaticamente pontos de extremidade de logon protegidos, resilientes e geograficamente distribuídos. Use a política de validate-azure-ad-token para validar tokens do Microsoft Entra em solicitações de API de entrada.
  • Quando a autenticação é necessária, o Gerenciamento de API dá suporte à validação de tokens de OAuth2, Autenticação básica, certificados de cliente e chaves de API.
    • Verifique a configuração adequada dos métodos de autenticação. Por exemplo, defina require-expiration-time e require-signed-tokens para true ao validar tokens OAuth2 usando a política validate-jwt.
  • Limite de taxa pode ser utilizado para reduzir a eficácia dos ataques de força bruta.
  • A Filtragem de IP do cliente pode ser usada para reduzir a área da superfície de ataque. Os grupos de segurança de rede podem ser aplicados a redes virtuais integradas ao Gerenciamento de API.
  • Se possível, autentique-se em back-ends do Gerenciamento de API por meio de protocolos seguros e identidade gerenciada ou gerenciador de credenciais para autenticar em back-ends.
  • Verifique se tokens ou chaves são passados em cabeçalhos e não URLs para solicitações de entrada para Gerenciamento de API e solicitações de saída para back-ends.
  • Use o Microsoft Entra para acesso seguro ao portal do desenvolvedor do Gerenciamento de API.

Autorização danificada de nível de propriedade do objeto

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, permitindo ataques de injeção de dados. Os invasores também podem descobrir interfaces não documentadas. Essas vulnerabilidades podem gerar dados confidenciais para o invasor.

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

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 interrupção, por exemplo, a adição de um campo a uma interface e versões para implementar alterações interruptivas. Você também deve ver interfaces de back-end, que normalmente têm um ciclo de vida diferente das APIs voltadas para o consumidor.
  • Desacople as interfaces de API externas na implementação de dados internos. Evite vincular contratos de API diretamente a contratos de dados em serviços de back-end.
  • 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. A validação de conteúdo 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. Por exemplo, remova propriedades JSON desnecessárias de um corpo de resposta. 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. A política validate-content também dá suporte ao bloqueio de respostas que excedem um tamanho especificado.
  • Use a política de validate-status-code para bloquear respostas com erros indefinidos no esquema da API.
  • Use a política de validate-headers 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 set-header.
  • Para cenários do GraphQL, use a política de validate-graphql-request para validar solicitações do GraphQL, autorizar o acesso a caminhos de consulta específicos e limitar o tamanho da resposta.

Consumo irrestrito de recursos

As APIs exigem que os recursos sejam executados, como memória ou CPU, e podem incluir integrações downstream que representam um custo operacional (por exemplo, serviços de pagamento por solicitação). A aplicação de limites pode ajudar a proteger as APIs contra o consumo excessivo de recursos.

Mais informações sobre essa ameaça: API4:2023 Consumo irrestrito de recursos

Recomendações

  • Use rate-limit-by-key ou políticas rate-limit para aplicar a limitação em janelas de tempo mais curtas. Aplique políticas de limitação de taxa mais rigorosas em pontos de extremidade confidenciais, como redefinição de senha, entrada ou operações de inscrição ou pontos de extremidade que consomem recursos significativos.
  • Use quota-by-key ou quota-limit para controlar o número permitido de chamadas à API ou largura de banda por períodos mais longos.
  • Otimize o desempenho com cache integrado, reduzindo assim o consumo de CPU, memória e recursos de rede para determinadas operações.
  • Aplicar políticas de validação.
    • Use max-size o atributo na política validate-content para impor o tamanho máximo de solicitações e respostas
    • Defina esquemas e propriedades, como comprimento da cadeia de caracteres ou tamanho máximo da matriz, na especificação da API. Use políticas de validate-content, validate-parameters, e validate-headers para impor esses esquemas para solicitações e respostas.
    • Use a política de validate-graphql-request para APIs do GraphQL e configurar os parâmetros max-depth e max-size.
    • Configure alertas no Azure Monitor para consumo excessivo de dados pelos usuários.
  • Para APIs de IA generativa:
  • 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.
    • Defina timeout na políticaforward-request e procure o valor aceitável mais curto.
    • Limite o número de conexões de back-end paralelas com a política de limit-concurrency.
  • 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.
  • Embora o Azure tenha proteção no nível da plataforma e proteção aprimorada contra ataques de DDoS (negação de serviço distribuído), a proteção do aplicativo (camada 7) para APIs pode ser aprimorada implantando 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. Ao usar uma política de firewall do aplicativo Web (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:2023 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 ou política de autorização em nível de APIs. Se aplicável, defina outras políticas de autorização para APIs ou operações de API específicas.
  • Valide tokens OAuth usando políticas.
    • Use a política de validate-azure-ad-token para validar tokens do Microsoft Entra. Especifique todas as declarações necessárias e, se aplicável, especifique os aplicativos autorizados.
    • Para validar tokens não emitidos pelo Microsoft Entra, defina uma política de validate-jwt e imponha as declarações de token necessárias. Se possível, exija tempo de expiração.
    • Se possível, use tokens criptografados ou liste aplicativos específicos para acesso.
    • Monitore e examine solicitações rejeitadas devido à falta de autorização.
  • 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.
  • Se os IPs do cliente forem conhecidos, use uma política de ip-filter para permitir o tráfego somente de endereços IP autorizados.
  • Use a política validate-client-certificate para impor que um certificado apresentado por um cliente a uma instância de Gerenciamento de API corresponda às regras e às declarações de validação especificadas.

Acesso irrestrito a fluxos de negócios confidenciais

As APIs podem expor uma ampla gama de funcionalidades ao aplicativo consumidor. É importante que os autores da API entendam os fluxos de negócios que a API fornece e a confidencialidade associada. Há um risco maior para a empresa se as APIs que expõem fluxos confidenciais não implementarem proteções apropriadas.

Mais informações sobre essa ameaça: API6:2023 Acesso irrestrito a fluxos comerciais confidenciais

Recomendações

  • Reduza ou bloqueie o acesso com base nas impressões digitais do cliente. Por exemplo, use a política de return-response com a política choose para bloquear o tráfego de navegadores sem cabeçalho com base no cabeçalho do Agente do Usuário ou na consistência de outros cabeçalhos.
  • Use a política validate-parameters para impor que os cabeçalhos de solicitação correspondam à especificação da API.
  • Use a política ip-filter para permitir solicitações somente de endereços IP conhecidos ou negar acesso de IPs específicos.
  • Use recursos de rede privada para limitar a conectividade externa a APIs internas.
  • Use a política de rate-limit-by-keypara limitar picos no consumo de API com base na identidade do usuário, endereço IP ou outro valor.
  • Gerenciamento de API Front com o Gateway de Aplicativo do Azure ou o serviço de Proteção contra DDoS do Azure para detectar e bloquear o tráfego de bot.

Falsificação de solicitação do lado do servidor

Uma vulnerabilidade de falsificação de solicitação do lado do servidor pode ocorrer quando a API busca um recurso downstream com base no valor de uma URL que foi passada pelo chamador de API sem as verificações de validação apropriadas.

Mais informações sobre essa ameaça: API7:2023 Falsificação de solicitação do lado do servidor

Recomendações

  • Se possível, não use URLs fornecidas nos conteúdos do cliente, por exemplo, como parâmetros para URLs de back-end, política send-request ou rewrite-url.
  • Se o Gerenciamento de API ou os serviços de back-end usarem URLs fornecidas no conteúdo da solicitação para lógica de negócios, defina e imponha uma lista limitada de nomes de host, portas, tipos de mídia ou outros atributos com políticas no Gerenciamento de API, como a política choose e as expressões de política.
  • Defina o atributo timeout nas políticas forward-request e send-request.
  • Valide e sanitize dados de solicitação e resposta com políticas de validação. Se necessário, use a política set-body para processar a resposta e evitar o retorno de dados brutos.
  • Use a rede privada para restringir a conectividade. Por exemplo, se a API não precisar ser pública, restrinja a conectividade da Internet para reduzir a superfície de ataque.

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 de forma desnecessária
  • Conexões de rede desnecessariamente abertas à Internet
  • Uso de protocolos ou criptografias fracos

Para obter mais informações sobre esta ameaça: API8:2023 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. Você pode auditar e impor essa configuração usando o Azure Policy.
  • 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 validate-jwt para verificar a existência e a validade do token 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. Se você usar o Microsoft Entra, a política de validate-azure-ad-token fornecerá uma maneira mais abrangente e fácil de validar tokens de segurança.
    • 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 validation policies para 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 validate-client-certificate. 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 validate-graphQL-request. 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 Azure 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.
  • Verifique se suas APIs exigem chaves de assinatura, mesmo que todos os produtos estejam configurados para exigir chaves de assinatura. Saiba mais
  • Exija aprovação de assinatura para todos os produtos e examinar cuidadosamente todas as solicitações de 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. Use a identidade gerenciada para autenticar cofres de chave.
  • 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.
  • Sempre que possível, use o gerenciador de credenciais ou a identidade gerenciada para se autenticar em serviços de back-end.
  • 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.

Gerenciamento de inventário inadequado

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:2023 Gerenciamento de inventário inadequado

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 gerenciar alterações de 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. Verifique se os controles de segurança são implementados em todas as versões de API disponíveis.
  • Ambientes separados (como desenvolvimento, teste e produção) com diferentes serviços de Gerenciamento de API. Verifique se cada serviço 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.
  • Isole permissões administrativas para APIs e recursos relacionados usando workspaces.
  • Use marcas para organizar APIs e produtos e agrupá-los para publicação.
  • Publique APIs para consumo por meio do portal do desenvolvedor. 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.
  • Use Centro de API do Azure para manter um inventário abrangente e centralizado de APIs, versões e implantações, mesmo que as APIs não sejam gerenciadas no Gerenciamento de API do Azure.

Consumo não seguro de APIs

Os recursos obtidos por meio de integrações downstream tendem a ser mais confiáveis do que a entrada de API do chamador ou do usuário final. Se os padrões de segurança e sanitização apropriados não forem aplicados, a API poderá ficar vulnerável, mesmo que a integração seja fornecida por meio de um serviço confiável.

Mais informações sobre essa ameaça: API10:2023 Consumo não seguro de APIs

Recomendações

  • Considere usar o Gerenciamento de API para atuar como uma fachada para dependências downstream com as quais as APIs de back-end se integram.
  • Se as dependências downstream forem fronted com o Gerenciamento de API ou se as dependências downstream forem consumidas com uma política de send-request no Gerenciamento de API, use as recomendações de outras seções desta documentação para garantir seu consumo seguro e controlado, incluindo:
    • Verifique se o transporte seguro está habilitado e impor a configuração TLS/SSL
    • Se possível, autentique com o gerenciador de credenciais ou a identidade gerenciada
    • Controlar o consumo com políticas de rate-limit-by-key e quota-limit-by-key
    • Registrar ou bloquear respostas que sejam incompatíveis com a especificação da API usando as políticas validate-content e validate-header
    • Transformar respostas com a política set-body, por exemplo, para remover informações desnecessárias ou confidenciais
    • Configurar tempos limite e limitar simultaneidade

Conteúdo relacionado

Saiba mais sobre: