Impedire acquisizioni di sottodominio nel servizio app di Azure

Le acquisizioni di sottodomini sono una minaccia comune per le organizzazioni che creano ed eliminano regolarmente molte risorse. Un'acquisizione di sottodominio può verificarsi quando è presente un record DNS che punta a una risorsa di Azure di cui è stato effettuato il deprovisioning. Tali record DNS sono noti anche come voci "DNS in sospeso". Le acquisizioni di sottodominio consentono agli attori malintenzionati di reindirizzare il traffico destinato al dominio di un'organizzazione a un sito che esegue attività dannose.

I rischi di acquisizione del sottodominio includono:

• Perdita di controllo sul contenuto del sottodominio
• Raccolta di biscotti da visitatori insospettabili
• Campagne di phishing
• Ulteriori rischi derivanti da attacchi classici, come XSS, CSRF o elusione di CORS.

Per altre informazioni sull'acquisizione del sottodominio, vedere Impedire voci DNS incerte ed evitare l'acquisizione del sottodominio.

Servizio app di Azure fornisce prenotazione del nome, token di verifica del dominio e nomi host predefiniti univoci e sicuri per impedire l'appropriazione di sottodomini.

Proteggere i nomi host predefiniti univoci (scelta consigliata)

Il modo più efficace per proteggere le risorse del servizio app dall'acquisizione del sottodominio consiste nell'usare nomi host predefiniti univoci sicuri. Questa funzionalità è disponibile a livello generale per App Web, App per le funzioni e App per la logica (Standard).

Quando si abilitano nomi host predefiniti univoci sicuri, l'app riceve un nome host predefinito che include un hash casuale e un identificatore di area, rendendolo univoco per l'organizzazione. Questo formato garantisce che nessuno all'esterno dell'organizzazione possa creare una risorsa con lo stesso nome host predefinito, eliminando così il rischio di acquisizione del sottodominio tramite voci DNS dangling.

Come funziona

Le risorse del servizio app tradizionali usano un formato hostname predefinito prevedibile a livello globale:

Ad esempio, un'app Web denominata contoso distribuita negli Stati Uniti orientali potrebbe ricevere:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

L'hash di 16 caratteri è deterministico all'interno di un ambito configurabile, quindi è possibile garantire nomi host coerenti tra gli ambienti quando necessario.

Opzioni dell'ambito dell'hash

Quando si crea una risorsa con un nome host predefinito univoco, si sceglie un ambito che determina la modalità di generazione dell'hash:

Slot di implementazione

Gli slot di distribuzione seguono lo stesso formato del sito di produzione, ma ogni slot riceve il proprio hash distinto:

Gli slot vengono sempre creati con lo stesso ambito del sito di produzione.

Come abilitare

È possibile abilitare nomi host predefiniti sicuri quando si crea una nuova risorsa tramite il portale di Azure, interfaccia della riga di comando di Azure, i modelli arm o l'API REST. La funzionalità può essere abilitata solo durante la creazione di risorse. Non può essere applicata retroattivamente alle risorse esistenti.

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

Migrazione di risorse esistenti

Poiché questa funzionalità può essere abilitata solo in fase di creazione, sono disponibili due opzioni per le risorse esistenti:

• Clonare un'app preesistente in una nuova app con nomi host predefiniti sicuri abilitati.
• Eseguire il ripristino da un backup a una nuova app con nomi host predefiniti univoci sicuri abilitati.

Entrambe le opzioni sono disponibili nel portale di Azure.

Perché adottare questo ora

I nomi host predefiniti univoci e sicuri forniscono protezione per impostazione predefinita. A differenza di altre strategie di mitigazione che richiedono l'igiene DNS in corso e l'intervento manuale, questo approccio crea la sicurezza direttamente nella struttura del nome host. Se abilitato/a:

• Nessun attore esterno può ricreare il nome host predefinito.
• Non è possibile sfruttare le voci DNS dangling per l'acquisizione del sottodominio.
• Non sono necessari passaggi di configurazione aggiuntivi oltre all'abilitazione della funzionalità in fase di creazione.

È consigliabile abilitare nomi host predefiniti univoci sicuri per tutte le nuove distribuzioni del servizio app.

Contenuti correlati

• Anteprima pubblica: creazione di un'app Web con un nome host predefinito univoco
• Nomi host predefiniti univoci e sicuri: disponibilità generale in App Service App Web e anteprima pubblica in Funzioni
• Nomi host predefiniti univoci e sicuri ora generalmente disponibili per App Funzioni e Logic

Come il servizio app impedisce le acquisizioni di sottodominio

Dopo l'eliminazione di un'app del servizio app o di un ambiente del servizio app (ASE), il DNS corrispondente non può essere riutilizzato, salvo per le sottoscrizioni che appartengono al tenant della sottoscrizione che originariamente possedeva il DNS. Di conseguenza, il cliente ha tempo per pulire le associazioni o i puntatori al DNS specificato o recuperare il DNS in Azure ricreando la risorsa con lo stesso nome. Questo comportamento è abilitato per impostazione predefinita nel servizio app di Azure per *.azurewebsites.net le risorse e *.appserviceenvironment.net , quindi non richiede alcuna configurazione del cliente.

Scenario di esempio

La sottoscrizione A e la sottoscrizione B sono le uniche sottoscrizioni che appartengono al tenant AB. Sottoscrizione A contiene un'app Web di Servizio app test con il nome DNS test.azurewebsites.net. Dopo l'eliminazione dell'app, solo le sottoscrizioni A o B possono riutilizzare immediatamente il nome test.azurewebsites.net DNS creando un'app Web denominata test. Nessun'altra sottoscrizione può rivendicare il nome immediatamente dopo l'eliminazione della risorsa.

Come evitare acquisizioni di sottodominio

Quando si creano voci DNS per il servizio app di Azure, creare un asuid.{ sottodominio} record TXT con l'ID di verifica del dominio. Quando esiste un record TXT di questo tipo, nessun'altra sottoscrizione di Azure può convalidare il dominio personalizzato o assumerla, a meno che non aggiungano il proprio ID di verifica del token alle voci DNS.

Questi record impediscono la creazione di un'altra app del servizio app usando lo stesso nome dalla voce CNAME. Senza la possibilità di dimostrare la proprietà del nome di dominio, gli attori delle minacce non possono ricevere traffico o controllare il contenuto.

I record DNS devono essere aggiornati prima dell'eliminazione del sito per garantire che gli attori malintenzionati non possano assumere il dominio tra il periodo di eliminazione e la ricreazione.

Per ottenere un ID di verifica del dominio, vedere Configurare un dominio personalizzato esistente nel servizio app di Azure.