Partilhar via

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

Nota

Este artigo foi atualizado para refletir a lista mais recente dos 10 principais de segurança da API 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:

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: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 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 GraphQL, imponha a autorização no nível do objeto por meio da política validate-graphql-request , usando o authorize elemento .

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 ativos e pontos de extremidade necessários para autenticação, incluindo fluxos de senha esquecida ou redefinição de senha, devem ser protegidos para evitar exploração.

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 do Microsoft Entra em solicitações de API de entrada.
  • 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 .
  • O 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 com o 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.
  • 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.

Autorização de nível de propriedade de objeto quebrado

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, 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 controlar graciosamente alterações ininterruptas, por exemplo, a adição de um campo a uma interface e versões para implementar alterações de quebra. Você também deve versões de interfaces de back-end, que normalmente têm um ciclo de vida diferente das APIs voltadas para o 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 com 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 rígidas em pontos de extremidade confidenciais, como operações de redefinição de senha, login ou inscrição, ou pontos de extremidade 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:
    • Use o cache semântico para reduzir a carga nos back-ends.
    • Use a limitação de token para controlar o consumo e os custos.
    • Emita métricas de consumo de token para monitorar a utilização do token e configurar alertas.
  • 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.
  • 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 quebrado

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 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 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 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 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 cabeça 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 de filtro ip 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 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 de solicitação de envio ou política de url de regravação .
  • Se o Gerenciamento de API ou os serviços de back-end usarem URLs fornecidas na carga útil de 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 de escolha e expressões de política.
  • Defina o timeout atributo nas políticas de solicitação de encaminhamento e solicitação de envio.
  • 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 retornar 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 proteçã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 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. Você pode auditar e impor essa configuração usando a Política do Azure.
  • 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 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 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 validate-client-certificate . 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 GraphQL, use a política validate-graphQL-request . Certifique-se de que o elemento e max-size max-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 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 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.
  • 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 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.

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). Planeje depreciar rapidamente e, finalmente, remover versões de API mais antigas, muitas vezes 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 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.
  • 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 por meio de um portal do 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 forem frontadas com o Gerenciamento de API ou se as dependências downstream forem consumidas com uma política de solicitação de envio no Gerenciamento de API, use as recomendações de outras seções desta documentação para garantir seu 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 taxa limite por chave e 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: