Partilhar via

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

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

Nota

Este artigo foi atualizado para refletir a lista mais recente dos Top 10 de Segurança de APIs da OWASP para 2023.

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, discutimos as recomendações mais recentes para mitigar 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 funcionalidades complementares para detetar ou proteger contra ameaças à API OWASP:

Falha na autorização de nível de objeto

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:2023 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 gerar 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 envio de solicitações.

  • Para cenários GraphQL, implemente a autorização ao nível do objeto através da política validate-graphql-request, utilizando o elemento authorize.

Autenticação quebrada

O mecanismo de autenticação de um site ou API é especialmente vulnerável porque está aberto a usuários anônimos. Os recursos e terminais necessários para autenticação, incluindo os fluxos de esquecimento ou redefinição de senha, devem ser protegidos para prevenir a exploração indevida.

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

Recomendações

  • Use o Microsoft Entra para implementar a autenticação de API. O Microsoft Entra fornece automaticamente pontos de extremidade de login protegidos, resilientes e distribuídos geograficamente. Use a política validate-azure-ad-token para validar tokens de Microsoft Entra em pedidos de entrada de API.
  • Onde a autenticação é necessária, o Gerenciamento de API suporta a validação de tokens OAuth 2, autenticação básica, certificados de cliente e chaves de API.
    • Garantir 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 .
  • Limitação de taxa pode ser usada 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 com o Gerenciamento de API.
  • Se possível, autentique-se em back-ends da Gestão de API por meio de protocolos seguros e utilize uma identidade gerida ou um gestor de credenciais para autenticar nos back-ends.
  • Certifique-se de que os tokens ou chaves sejam passados em cabeçalhos e não URLs para solicitações de entrada para o Gerenciamento de API e solicitações de saída para back-ends.
  • Use o Microsoft Entra para proteger o acesso ao portal do desenvolvedor do Gerenciamento de API.

Vulnerabilidade na autorização a nível de propriedade de objeto

Um bom design de interface de API é desafiador de forma enganosa. 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 atacantes também podem descobrir interfaces não documentadas. Essas vulnerabilidades podem gerar dados confidenciais para o invasor.

Mais informações sobre esta ameaça: API3:2023 Broken Object Property Level Authorization

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 gerir de forma suave alterações ininterruptas, por exemplo, a adição de um campo a uma interface, e versões para implementar alterações disruptivas. Você também deve versionar interfaces de back-end, que normalmente têm um ciclo de vida diferente das APIs direcionadas ao consumidor.
  • Desacople interfaces de API externas da 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 úteis 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 inadequados. Por exemplo, remova propriedades JSON desnecessárias de um corpo de resposta. 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. A política de conteúdo validado também suporta o bloqueio de respostas que excedam um tamanho especificado.
  • Use a política validate-status-code para bloquear respostas com erros indefinidos no esquema da API.
  • Use a política 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 usando a política set-header.
  • Para cenários GraphQL, use a política validate-graphql-request para validar solicitações GraphQL, autorizar o acesso a caminhos de consulta específicos e limitar o tamanho da resposta.

Consumo irrestrito de recursos

As APIs exigem recursos para serem executadas, 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 do consumo excessivo de recursos.

Mais informações sobre esta ameaça: API4:2023 Unrestricted Resource Consumption

Recomendações

  • Use políticas de limite de taxa por chave ou limite de taxa para aplicar a limitação em janelas de tempo mais curtas. Aplique políticas de limitação de taxa mais rigorosas em endpoints sensíveis, como as operações de redefinição de senha, login ou inscrição, ou endpoints que consomem recursos significativos.
  • Use políticas de cota por chave ou limite de cota para controlar o número permitido de chamadas de API ou largura de banda para períodos de tempo mais longos.
  • Otimize o desempenho com cache integrado, reduzindo assim o consumo de CPU, memória e recursos de rede para determinadas operações.
  • Aplique políticas de validação.
  • Para APIs de IA generativas:
  • 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.
    • Defina timeout na política de encaminhamento de solicitação e esforce-se pelo menor valor aceitável.
    • Limite o número de conexões paralelas de back-end com a política 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 distribuídos de negação de serviço (DDoS), a proteção de aplicativos (camada 7) para APIs pode ser aprimorada implantando um serviço de proteção de bot na frente do Gerenciamento de API - por exemplo, Azure Application Gateway, Azure Front Door ou Azure DDoS Protection. Ao usar uma política de firewall de aplicativo Web (WAF) com o Azure Application Gateway ou o Azure Front Door, considere usar o Microsoft_BotManagerRuleSet_1.0.

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

Políticas complexas de controle de acesso 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.

Mais informações sobre esta ameaça: API5:2023 Autorização quebrada ao nível da função

Recomendações

  • Por padrão, proteja todos os pontos de extremidade da API no Gerenciamento de API com chaves de assinatura ou política de autorização em todos os níveis 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 validate-azure-ad-token para validar tokens 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 validate-jwt e imponha as declarações de token necessárias. Se possível, exija tempo de validade.
    • Se possível, use tokens criptografados ou liste aplicativos específicos para acesso.
    • Monitorar e analisar solicitações rejeitadas por falta de autorização.
  • 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.
  • Se os IPs do cliente forem conhecidos, use uma política de filtro de ip 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 de validação e declarações especificadas.

Acesso irrestrito a fluxos de negócios sensíveis

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 sensibilidade associada. Há um risco maior para os negócios se as APIs que expõem fluxos confidenciais não implementarem proteções adequadas.

Mais informações sobre essa ameaça: API6:2023 Acesso irrestrito a fluxos de negócios confidenciais

Recomendações

  • Reduza ou bloqueie o acesso com base nas impressões digitais do cliente. Por exemplo, use a política de retorno-resposta com a política de escolha para bloquear o tráfego de navegadores sem interface com base no cabeçalho User-Agent 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 apenas de endereços IP conhecidos ou negar o acesso de IPs específicos.
  • Use recursos de rede privada para limitar a conectividade externa a APIs internas.
  • Use a política de limite de taxa por chave para limitar picos no consumo de API com base na identidade do usuário, endereço IP ou outro valor.
  • Gerenciamento de API frontal com o Gateway de Aplicativo do Azure ou o serviço de Proteção contra DDoS do Azure para detetar e bloquear o tráfego de bots.

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 da API sem verificações de validação apropriadas.

Mais informações sobre esta ameaça: API7:2023 Server Side Request Forgery

Recomendações

  • Se possível, não use URLs fornecidas nas cargas úteis do cliente, por exemplo, como parâmetros para URLs de back-end, política send-request ou política de rewrite-url.
  • Se a Gestão de API ou os serviços de back-end utilizarem URLs fornecidas na carga útil de solicitação para lógica de negócios, defina e aplique uma lista restrita de nomes de host, portas, tipos de media ou outros atributos com políticas na Gestão de API, como a política escolher e expressões de política.
  • Defina o atributo timeout nas políticas forward-request e send-request.
  • Valide e limpe os 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 atacantes podem tentar explorar vulnerabilidades de configuração incorreta de segurança, tais como:

  • Falta de reforço de segurança
  • Recursos habilitados desnecessariamente
  • Ligações de rede desnecessariamente abertas à Internet
  • Uso de protocolos fracos ou cifras

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

Recomendações

  • Configure corretamente o gateway TLS. 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. Você pode auditar e impor essa configuração usando a Política do Azure.
  • Considere implantar a Gestão de API atrás de um endpoint privado ou conectado a uma rede virtual implementada em 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).
  • Utilize as políticas de Gestão de API do Azure:
    • Sempre herde políticas principais através da tag <base>.
    • Ao usar o OAuth 2.0, configure e teste a política 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. Imponha 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 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 políticas de validação 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 de solicitação ou resposta.
    • Se a Gestão de API estiver fora dos limites da rede, a validação de IP do cliente ainda será possível usando a política de 'restringir IPs' 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 a Gestão de API, use a política validate-client-certificate. Certifique-se de que os atributos validate-revocation, validate-trust, validate-not-before e validate-not-after estejam 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 GraphQL, use a política validate-graphQL-request. Certifique-se de que o elemento authorization e os atributos max-size e max-depth estão definidos.
  • Não armazene segredos em arquivos de política ou no controle do código-fonte. Sempre use valores nomeados de Gerenciamento de API ou busque os segredos durante o tempo de execução usando expressões de política personalizadas. Os valores nomeados devem ser integrados ao Cofre de Chaves do Azure 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.
  • Certifique-se de que suas APIs exijam chaves de assinatura, mesmo que todos os produtos estejam configurados para exigir chaves de assinatura. Mais informações
  • Exija aprovação de subscrição para todos os produtos e analise cuidadosamente todos os pedidos de subscrição.
  • 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. Use a identidade gerenciada para autenticar em cofres de chaves.
  • Ao usar o self-hosted-gateway, assegure-se de que exista um processo em vigor para atualizar a imagem periodicamente para a versão mais recente.
  • 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.
  • Certifique-se de que seus back-ends estejam protegidos contra ataques de travessia de caminho (passagem de diretório). A Gestão de API pode encaminhar solicitações contendo ..%2f no caminho da URL para um back-end. Se o back-end decodificá-lo para ../, ele pode ser suscetível a um ataque de travessia de caminho. Você também pode aplicar uma política no Gerenciamento de API para detetar e bloquear solicitações, como as contidas ..%2f no caminho.
  • Sempre que possível, use o gerenciador de credenciais ou a identidade gerenciada para autenticar em serviços de back-end.
  • 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 Microsoft Entra External ID para inscrição e entrada do usuário. 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 Azure Policy para impor a configuração de nível de recursos no Gerenciamento de API e permissões de controle de acesso baseado em funções (RBAC) para garantir o controle do 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.

Gestão inadequada de inventário

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 essa ameaça: API9:2023 Gerenciamento de inventário inadequado

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 gerenciar alterações de 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). Planeie descontinuar rapidamente e, por fim, remover versões de API mais antigas e, frequentemente, menos seguras. Garanta que os controles de segurança sejam 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. Certifique-se de que cada serviço 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 as práticas de automação DevOps e de infraestrutura como código para ajudar a manter a consistência e a precisão nos ambientes e reduzir erros humanos.
  • Isolar permissões administrativas para APIs e recursos relacionados usando espaços de trabalho.
  • Use tags para organizar APIs e produtos e agrupá-los para publicação.
  • Publique APIs para consumo através de um portal de desenvolvedor. 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.
  • Use a Central de APIs 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 inseguro 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 adequados de sanitização e segurança não forem aplicados, a API pode ficar vulnerável, mesmo que a integração seja fornecida por meio de um serviço confiável.

Mais informações sobre esta 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 estiverem protegidas pela gestão de API ou se forem consumidas com uma política send-request na gestão de API, utilize as recomendações de outras secções desta documentação para garantir um consumo seguro e controlado, incluindo:
    • Garantir que o transporte seguro esteja habilitado e impor a configuração TLS/SSL
    • Se possível, autentique-se com o gerenciador de credenciais ou identidade gerenciada
    • Controle o consumo com políticas de limitação de taxa por chave e limitação de cota por chave.
    • Registrar ou bloquear respostas incompatíveis com a especificação da API usando as políticas validate-content e validate-header
    • Transforme as respostas com a política set-body, por exemplo, para remover informações desnecessárias ou confidenciais
    • Configurar tempos limite e limitar simultaneidade

Conteúdos relacionados

Saiba mais sobre:

  • Last updated on