Förhindra underdomänövertaganden i Azure App Service

Underdomänövertaganden är ett vanligt hot för organisationer som regelbundet skapar och tar bort många resurser. Ett underdomänövertagande kan ske när du har en DNS-post som pekar på en avetablerad Azure-resurs. Sådana DNS-poster kallas även "dinglande DNS"-poster. Underdomänövertaganden gör det möjligt för skadliga aktörer att omdirigera trafik som är avsedd för en organisations domän till en webbplats som utför skadlig aktivitet.

Riskerna med underdomänövertagande omfattar:

• Förlust av kontroll över innehållet i underdomänen
• Insamling av kakor från intet ont anande besökare
• Nätfiskekampanjer
• Ytterligare risker för klassiska attacker som XSS, CSRF eller CORS bypass

Mer information om övertagande av underdomäner finns i Förhindra dinglande DNS-poster och undvika övertagande av underdomäner.

Azure App Service tillhandahåller namnreservation, domänverifieringstoken och säkra unika standardvärdnamn för att förhindra underdomänövertaganden.

Skydda unika standardvärdnamn (rekommenderas)

Det mest effektiva sättet att skydda dina App Service-resurser från underdomänövertagande är att använda säkra unika standardvärdnamn. Den här funktionen är allmänt tillgänglig för Web Apps, Funktionsappar och Logic Apps (Standard).

När du aktiverar säkra unika standardvärdnamn får din app ett standardvärdnamn som innehåller en slumpmässig hash och en regionidentifierare, vilket gör den unik för din organisation. Det här formatet säkerställer att ingen utanför organisationen kan skapa en resurs med samma standardvärdnamn, vilket eliminerar risken för underdomänövertagande genom dinglande DNS-poster.

Så här fungerar det

Traditionella App Service-resurser använder ett standardformat för värdnamn som är globalt förutsägbart:

En webbapp med namnet contoso som har distribuerats till East US kan till exempel få:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

Hashen på 16 tecken är deterministisk inom ett konfigurerbart omfång, så du kan säkerställa konsekventa värdnamn i olika miljöer när det behövs.

Alternativ för hashningsomfång

När du skapar en resurs med ett unikt standardvärdnamn väljer du ett omfång som avgör hur hashen genereras:

Distributionsplatser

Distributionsplatser följer samma format som produktionswebbplatsen, men varje plats får ett eget unikt hashvärde:

Slotar skapas alltid med samma omfång som produktionswebbplatsen.

Så här aktiverar du

Du konfigurerar säkra unika standardvärdnamn när du skapar resursen. Du kan inte tillämpa dem retroaktivt på befintliga resurser. Hur du aktiverar dem beror på vilken klient du använder:

• Azure-portalen: Nya Web Apps, Function Apps och Logic Apps (Standard) skapade i Azure-portalen använder automatiskt säkra unika standardvärdnamn på alla stödda SKU:er. Ingen extra konfiguration krävs.
• Azure CLI, ARM-mallar och REST API: Du måste välja att delta uttryckligen genom att sätta hostname-scope på skapa-begäran. Sätt detta värde för varje ny distribution så att resurser skapade utanför portalen använder samma standard värdnamnsformat som resurser skapade i portalen.

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

Migrera befintliga resurser

Eftersom den här funktionen bara kan aktiveras när den skapas har du två alternativ för befintliga resurser:

• Klona en befintlig app till en ny app med säkra unika standardvärdnamn aktiverade.
• Återställ från en säkerhetskopia till en ny app med säkra unika standardvärdnamn aktiverade.

Båda alternativen är tillgängliga i Azure portalen.

Varför anta detta nu

Säkra unika standardvärdnamn ger skydd som standard. Till skillnad från andra åtgärdsstrategier som kräver pågående DNS-hygien och manuella åtgärder bygger den här metoden in säkerhet direkt i värdnamnsstrukturen. När aktiverad:

• Ingen extern aktör kan återskapa ditt standardvärdnamn.
• Hängande DNS-poster kan inte utnyttjas för att ta över en underdomän.
• Inga ytterligare konfigurationssteg krävs utöver att aktivera funktionen vid skapandetillfället.

Använd säkra unika standardvärdnamn för varje ny App Service-distribution. Azure-portalen tillämpar redan denna konfiguration automatiskt för nya resurser på stödda SKU:er. Att anpassa dina Azure CLI-, ARM-mall- och REST API-utplaceringar med samma standardformat för värdnamn håller din provisionering konsekvent med den rekommenderade App Service-konfigurationen.

Relaterat innehåll

• Offentlig förhandsversion: Skapa webbapp med ett unikt standardvärdnamn
• Säkra unika standardvärdnamn: allmänt tillgänglig för App Service Web Apps och i offentlig förhandsversion för Functions
• Säkra unika standardvärdnamn är nu allmänt tillgängliga för Functions och Logic Apps

Så förhindrar App Service underdomänövertaganden

Vid borttagning av en App Service-app eller App Service Environment (ASE) får motsvarande DNS inte återanvändas förutom av prenumerationer som tillhör klientorganisationen för den prenumeration som ursprungligen ägde DNS. Kunden har därför lite tid på sig att antingen rensa eventuella associationer eller pekare till den nämnda DNS:n eller återta DNS i Azure genom att återskapa resursen med samma namn. Det här beteendet är aktiverat som standard i Azure App Service för *.azurewebsites.net och *.appserviceenvironment.net resurser, så det kräver ingen kundkonfiguration.

Exempelscenario

Prenumeration A och prenumeration B är de enda prenumerationer som tillhör klientorganisationen AB. Prenumeration A innehåller ett App Service-webbapptest med DNS-namnet test.azurewebsites.net. När appen har tagits bort kan endast prenumerationer A eller B återanvända DNS-namnet test.azurewebsites.net omedelbart genom att skapa en webbapp med namnet test. Inga andra prenumerationer kan göra anspråk på namnet direkt efter resursborttagningen.

Så här kan du förhindra underdomänövertaganden

När du skapar DNS-poster för Azure App Service skapar du en asuid.{ subdomain} TXT-post med domänverifierings-ID:t. När en sådan TXT-post finns kan ingen annan Azure-prenumeration verifiera den anpassade domänen eller ta över den om de inte lägger till sitt tokenverifierings-ID till DNS-posterna.

Dessa poster förhindrar att en annan App Service-app skapas med samma namn från CNAME-posten. Utan möjligheten att bevisa ägarskap för domännamnet kan hotaktörer inte ta emot trafik eller kontrollera innehållet.

DNS-poster bör uppdateras innan webbplatsen tas bort för att säkerställa att dåliga aktörer inte kan ta över domänen mellan borttagningsperioden och återskapandet.

Information om hur du hämtar ett domänverifierings-ID finns i Konfigurera en befintlig anpassad domän i Azure App Service.