Prevenir apropriações de subdomínios no serviço Azure App

As aquisições de subdomínios são uma ameaça comum para organizações que criam e excluem regularmente muitos recursos. Pode ocorrer uma obtenção de controlo de subdomínio quando tem um registo DNS que aponta para um recurso do Azure desaprovisionado. Esses registos DNS também são conhecidos como entradas "DNS pendentes". As aquisições de subdomínios permitem que atores maliciosos redirecionem o tráfego destinado ao domínio de uma organização para um site que realize atividades maliciosas.

Os riscos de aquisição de subdomínios incluem:

  • Perda de controle sobre o conteúdo do subdomínio
  • Colheita de cookies de visitantes desavisados
  • Campanhas de phishing
  • Riscos adicionais de ataques clássicos como XSS, CSRF ou CORS bypass

Para saber mais sobre a tomada de subdomínio, consulte Prevenir entradas DNS pendentes e evitar tomada de subdomínio.

O Serviço de Aplicações do Azure fornece reserva de nomes, tokens de verificação de domínio e nomes de anfitrião predefinidos, únicos e seguros para evitar a apropriação de subdomínios.

A forma mais eficaz de proteger os recursos do seu Serviço de Aplicações contra a aquisição de subdomínios é usar nomes de host predefinidos únicos e seguros. Esta funcionalidade está geralmente disponível para Aplicações Web, Function Apps e Logic Apps (Standard).

Quando ativa nomes de host predefinidos únicos e seguros, a sua aplicação recebe um nome de host predefinido que inclui um hash aleatório e um identificador de região, tornando-o único para a sua organização. Este formato garante que ninguém fora da sua organização pode criar um recurso com o mesmo nome de host predefinido, o que elimina o risco de tomada de subdomínio através de entradas DNS pendentes.

Como funciona

Os recursos tradicionais de Serviços de Aplicação utilizam um formato de nome de host predefinido que é globalmente previsível:

Global (original) Único (novo)
Nome de host padrão <AppName>.azurewebsites.net <AppName>-<Hash>.<Region>.azurewebsites.net
Ponto final SCM <AppName>.scm.azurewebsites.net <AppName>-<Hash>.scm.<Region>.azurewebsites.net

Por exemplo, uma aplicação Web denominada contoso implementada nos E.U.A. Leste pode receber:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

O hash de 16 caracteres é determinístico dentro de um âmbito configurável, por isso pode garantir nomes de host consistentes entre ambientes quando necessário.

Opções de âmbito do hash

Quando cria um recurso com um nome de host predefinido único, escolhe um escopo que determina como o hash é gerado:

Scope Description
Reutilização de Inquilinos Mesmo hash para o mesmo nome de aplicação em todas as subscrições no seu tenant Microsoft Entra. Utilize esta opção ao reimplementar recursos entre subscrições no mesmo tenant.
Reutilização de Subscrição Mesmo hash para o mesmo nome de aplicação dentro da mesma subscrição.
Reutilização de grupos de recursos Mesmo hash para o mesmo nome de aplicação dentro do mesmo grupo de recursos.
Sem reutilização Hash único sempre. Isolamento máximo.

Sugestão

Se reimplementa regularmente recursos entre ambientes (por exemplo, de uma subscrição de teste para uma subscrição de produção no mesmo inquilino), utilize Reutilização do Inquilino para garantir que os nomes de anfitrião permanecem consistentes entre subscrições.

Espaços de implantação

Os slots de implantação seguem o mesmo formato do local de produção, mas cada slot recebe o seu próprio hash distinto:

Nome de anfitrião predefinido Nome do anfitrião da ranhura
Formato <AppName>-<Hash>.<Region>.azurewebsites.net <AppName>-<SlotName>-<Hash>.<Region>.azurewebsites.net

Os slots são sempre criados no mesmo âmbito que o site de produção.

Como ativar

Pode ativar nomes de host únicos e seguros ao criar um novo recurso através do portal Azure, CLI do Azure, templates ARM ou API REST. A funcionalidade só pode ser ativada durante a criação de recursos — não pode ser aplicada retroativamente a recursos existentes.

Use o --domain-name-scope parâmetro ao criar um novo recurso para permitir nomes de host únicos e seguros por defeito.

Tipo de recurso Comando Reference
Aplicações Web az webapp create --name <AppName> --resource-group <ResourceGroup> --plan <AppServicePlan> --domain-name-scope TenantReuse az webapp criar
Aplicações Funcionais az functionapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --consumption-plan-location <Region> --domain-name-scope TenantReuse az functionapp criar
Logic Apps (Padrão) az logicapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --domain-name-scope TenantReuse az logicapp create

O --domain-name-scope parâmetro aceita os seguintes valores: NoReuse, ResourceGroupReuse, SubscriptionReuse, TenantReuse.

Migração de recursos existentes

Como esta funcionalidade só pode ser ativada na criação, tem duas opções para os recursos existentes:

  • Clonar uma aplicação existente para uma nova aplicação com nomes de anfitrião predefinidos, únicos e seguros.
  • Restaurar a partir de uma cópia de segurança para uma nova aplicação com nomes de host predefinidos únicos e seguros ativados.

Ambas as opções estão disponíveis no portal Azure.

Porque adotar isto agora

Nomes de anfitrião predefinidos, únicos e seguros, proporcionam proteção por defeito. Ao contrário de outras estratégias de mitigação que exigem higiene DNS contínua e intervenção manual, esta abordagem integra a segurança diretamente na estrutura do nome do host. Quando ativado:

  • Nenhum ator externo pode recriar o teu nome de host padrão.
  • Entradas DNS pendentes não podem ser exploradas para tomada de subdomínio.
  • Não são necessários passos adicionais de configuração além de ativar a funcionalidade no momento da criação.

Recomendamos vivamente ativar nomes de host predefinidos únicos e seguros para todas as novas implementações de Serviços de Aplicações.

Note

O identificador de região no nome do host (por exemplo, eastus-01) pode usar sufixos numéricos diferentes para futuras implementações. Não estabeleça dependências estritas da combinação exata de região e número.

Como o Serviço de Aplicativo impede aquisições de subdomínios

Após a eliminação de uma aplicação de Serviço de Aplicações ou de um Ambiente de Serviços de Aplicação (ASE), o DNS correspondente é proibido de ser reutilizado, exceto por subscrições que pertençam ao inquilino da subscrição que originalmente possuía o DNS. Assim, o cliente tem algum tempo para limpar quaisquer associações ou ponteiros para o referido DNS ou recuperar o DNS no Azure recriando o recurso com o mesmo nome. Este comportamento está ativado por padrão no Serviço de Aplicações do Azure para os recursos *.azurewebsites.net e *.appserviceenvironment.net, por isso não requer qualquer configuração do cliente.

Cenário de exemplo

A subscrição A e a subscrição B são as únicas subscrições que pertencem ao tenant AB. A subscrição A contém uma aplicação web do Serviço de Aplicações test com o nome DNS test.azurewebsites.net. Após a eliminação da aplicação, apenas as subscrições A ou B conseguem reutilizar imediatamente o nome test.azurewebsites.net DNS criando uma aplicação web chamada test. Nenhuma outra subscrição pode reivindicar o nome logo após a eliminação do recurso.

Como você pode evitar aquisições de subdomínios

Ao criar entradas DNS para Serviço de Aplicações do Azure, crie um asuid.{ subdomínio} registo TXT com o ID de verificação do domínio. Quando tal registo TXT existe, nenhuma outra subscrição Azure pode validar o domínio personalizado ou assumi-lo, a menos que adicione o seu ID de verificação de token às entradas DNS.

Esses registros impedem a criação de outro aplicativo do Serviço de Aplicativo usando o mesmo nome da sua entrada CNAME. Sem a capacidade de provar a propriedade do nome de domínio, os agentes de ameaças não podem receber tráfego ou controlar o conteúdo.

Os registros DNS devem ser atualizados antes da exclusão do site para garantir que agentes mal-intencionados não possam assumir o domínio entre o período de exclusão e recriação.

Para obter um ID de verificação de domínio, veja Configurar um domínio personalizado existente no Serviço de Aplicações do Azure.