Empêcher les acquisitions de sous-domaines dans Azure App Service

Les prises de contrôle des sous-domaines sont une menace courante pour les organisations qui créent et suppriment régulièrement de nombreuses ressources. Une prise de contrôle de sous-domaine peut se produire lorsque vous avez un enregistrement DNS qui pointe vers une ressource Azure déprovisionnée. Ces enregistrements DNS sont également appelés entrées « DNS non résolues ». Les prises de contrôle des sous-domaines permettent aux acteurs malveillants de rediriger le trafic destiné au domaine d’une organisation vers un site effectuant une activité malveillante.

Les risques de prise en charge du sous-domaine sont les suivants :

• Perte de contrôle sur le contenu du sous-domaine
• Récolte de cookies à partir de visiteurs insoupçonnés
• Campagnes d’hameçonnage
• D’autres risques liés aux attaques classiques comme XSS, CSRF ou le contournement de CORS

Pour plus d’informations sur la prise de contrôle de sous-domaines, consultez Empêcher les entrées DNS danglantes et éviter la prise de contrôle de sous-domaine.

Azure App Service fournit la réservation de nom, des jetons de vérification de domaine et des noms d’hôte par défaut uniques et sécurisés pour empêcher la prise de contrôle de sous-domaines.

Sécuriser les noms d’hôte par défaut uniques (recommandé)

La façon la plus efficace de protéger vos ressources App Service contre la prise de contrôle de sous-domaine consiste à utiliser des noms d’hôte par défaut uniques sécurisés. Cette fonctionnalité est généralement disponible pour Web Apps, Function Apps et Logic Apps (Standard).

Lorsque vous activez des noms d’hôte par défaut uniques sécurisés, votre application reçoit un nom d’hôte par défaut qui inclut un hachage aléatoire et un identificateur de région, ce qui le rend unique à votre organisation. Ce format garantit que personne en dehors de votre organisation ne peut créer une ressource avec le même nom d’hôte par défaut, ce qui élimine le risque de prise en charge du sous-domaine par le biais d’entrées DNS déanglantes.

Fonctionnement

Les ressources App Service traditionnelles utilisent un format de nom d’hôte par défaut qui est globalement prévisible :

Par exemple, une application web nommée contoso déployée dans la région USA Est peut recevoir :

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

Le hachage de 16 caractères est déterministe dans une étendue configurable. Vous pouvez donc garantir des noms d’hôte cohérents entre les environnements si nécessaire.

Options de portée du hachage

Lorsque vous créez une ressource avec un nom d’hôte par défaut unique, vous choisissez une étendue qui détermine la façon dont le hachage est généré :

Emplacements de déploiement

Les emplacements de déploiement suivent le même format que le site de production, mais chaque emplacement reçoit son propre hachage distinct :

Les emplacements sont toujours créés avec la même étendue que le site de production.

Comment activer

Vous configurez des noms d’hôte par défaut uniques et sécurisés lors de la création de la ressource. On ne peut pas les appliquer rétroactivement aux ressources existantes. La façon dont vous les activez dépend du client que vous utilisez :

• Portail Azure : Les nouvelles Web Apps, Function Apps et Logic Apps (Standard) créées dans le portail Azure utilisent automatiquement des noms d’hôte par défaut uniques et sécurisés sur tous les SKU pris en charge. Aucune configuration supplémentaire n’est requise.
• Azure CLI, modèles ARM et API REST : Vous devez vous inscrire explicitement en définissant la portée du nom d’hôte sur la requête de création. Définissez cette valeur pour chaque nouveau déploiement afin que les ressources créées en dehors du portail utilisent le même format de nom d’hôte par défaut que les ressources créées dans le portail.

{
    "location": "Central US",
    "kind": "app",
    "properties": {
        "serverFarmId": "<AppServicePlanResourceId>",
        "AutoGeneratedDomainNameLabelScope": "TenantReuse"
    }
}

Migration des ressources existantes

Étant donné que cette fonctionnalité ne peut être activée qu’au moment de la création, vous disposez de deux options pour les ressources existantes :

• Clonez une application préexistante vers une nouvelle application avec des noms d’hôte par défaut uniques sécurisés activés.
• Restaurez à partir d’une sauvegarde vers une nouvelle application avec des noms d’hôte par défaut uniques sécurisés activés.

Les deux options sont disponibles dans le portail Azure.

Pourquoi adopter cela maintenant

Les noms d’hôte par défaut uniques sécurisés fournissent une protection par défaut. Contrairement à d’autres stratégies d’atténuation nécessitant une hygiène DNS continue et une intervention manuelle, cette approche génère la sécurité directement dans la structure du nom d’hôte. Quand cette option est activée :

• Aucun acteur externe ne peut recréer votre nom d’hôte par défaut.
• Les entrées DNS orphelines ne peuvent pas être exploitées pour une prise de contrôle d’un sous-domaine.
• Aucune étape de configuration supplémentaire n’est nécessaire au-delà de l’activation de la fonctionnalité au moment de la création.

Utilisez des noms d’hôte par défaut uniques et sécurisés pour chaque nouveau déploiement de service applicatif. Le portail Azure applique déjà automatiquement cette configuration pour les nouvelles ressources sur les SKU pris en charge. Aligner vos déploiements Azure CLI, template ARM et API REST avec le même format d’hôte par défaut maintient votre provisionnement cohérent avec la configuration recommandée du service d’application.

Contenu connexe

• Préversion publique : création d’une application web avec un nom d’hôte par défaut unique
• Noms d’hôte uniques et sécurisés par défaut : en disponibilité générale sur App Service Web Apps et en préversion publique sur Functions
• Noms d’hôte par défaut uniques sécurisés désormais en disponibilité générale pour Functions et Logic Apps

Comment App Service empêche les prises de contrôle des sous-domaines

Lors de la suppression d’une application App Service ou d’un environnement App Service (ASE), le DNS correspondant n’est pas réutilisable, sauf par les abonnements appartenant au locataire de l’abonnement qui possédait initialement le DNS. Par conséquent, le client a un certain temps pour nettoyer les associations ou les pointeurs vers le DNS indiqué ou récupérer le DNS dans Azure en recréant la ressource avec le même nom. Ce comportement est activé par défaut sur Azure App Service pour *.azurewebsites.net et *.appserviceenvironment.net ressources. Il ne nécessite donc aucune configuration client.

Exemple de scénario

L’abonnement A et l’abonnement B sont les seuls abonnements appartenant au locataire AB. L’abonnement A contient une application web App Service test avec le nom DNS test.azurewebsites.net. Lors de la suppression de l’application, seuls les abonnements A ou B sont en mesure de réutiliser immédiatement le nom test.azurewebsites.net DNS en créant une application web nommée test. Aucun autre abonnement n’est autorisé à revendiquer le nom juste après la suppression de la ressource.

Comment empêcher les prises de contrôle des sous-domaines

Lors de la création d’entrées DNS pour Azure App Service, créez un asuid.{subdomain} enregistrement TXT avec l’ID de vérification du domaine. Lorsqu’un enregistrement TXT de ce type existe, aucun autre abonnement Azure ne peut valider le domaine personnalisé ou le prendre en charge, sauf s’ils ajoutent leur ID de vérification de jeton aux entrées DNS.

Ces enregistrements empêchent la création d’une autre application App Service à l’aide du même nom que votre entrée CNAME. Sans pouvoir prouver la propriété du nom de domaine, les acteurs de menace ne peuvent pas recevoir de trafic ni contrôler le contenu.

Les enregistrements DNS doivent être mis à jour avant la suppression du site pour s’assurer que les acteurs incorrects ne peuvent pas reprendre le domaine entre la période de suppression et la recréation.

Pour obtenir un ID de vérification de domaine, consultez Configurer un domaine personnalisé existant dans Azure App Service.