Y
YutangLin
App Service now allows you to create web apps with unique default hostnames to avoid a high-severity threat of subdomain takeover.
This feature is currently in Public Preview and is only available for web apps on multi-tenants. App Service Environment (ASE) resources are not supported. Functions and Logic Apps (Standard) are currently out of scope, but we have plans on supporting them soon, so stay tuned.
This feature would require you to “opt-in” to create a site with a unique default hostname. This means that when you create a site through the portal, you will need to select the option to enable the feature; Azure Portal will be fully deployed by June 7th, 2024. When you create a site through ARM, you will need to provide your deployment templates with new parameters. You will not be able to update pre-existing web apps to create unique default hostnames; unique default hostnames can only be opt-in during web app resource creation.
This article will go over the following:
What are dangling DNS and subdomain takeover?
One of the most common scenarios for subdomain takeover is when a customer forgets to clear the DNS entries after deleting a pre-existing web causing dangling DNS. A bad actor could come in and create a web app with the same name and use the pre-existing DNS records to takeover domains because the web app will still have the same default hostname as the previously deleted one. You can learn more about dangling DNS and subdomain takeover here.
How does this feature work?
The unique default hostname will have a different format than the original global default hostname in two ways. The unique default hostname will include:
Comparing the format between the global (original) default hostnames and the unique (new) default hostnames, here is how the general format would look like:
As an example, if you create a site called “test” in East US:
How does the hash in the unique default hostname work
The hash used for the unique default hostname would be a 16-character hash. This hash could be configured to a given “scope”, which ensures the degree of how unique you would like default hostname to be.
You can choose to generate the hash based on the following “scopes”:
So as an example, for my site called “test”, I could choose to generate a hash that could be shared across my subscription if I selected the “Subscription Reuse”. What this means is that anyone in my subscription who tries to create a web app called “test” in any region using the “Subscription Reuse” will end up with the same hash as I would. Anyone else outside of my subscription who tries to create a site name called “test” will not end up with the same hash as I would.
If your team tends to redeploy web apps in different environments for testing, it could be helpful to select a scope that is shared between environments. As an example, I have both Subscription AA (test subscription) and Subscription AB (production subscription) under Tenant A, and I tend to redeploy resources from Subscriptions AA to AB. What I should do is to deploy a site with the unique default hostname that uses the “Tenant Reuse” in Subscription AA because both subscriptions share the same tenant. Then when I need to delete and redeploy in Subscription AB, I should keep using Tenant Reuse. This ensures that the site I create will still have the exact same default hostname. More importantly, during the period that I try to delete and redeploy my resource, no one else outside of my tenant would be able to recreate another site with the exact same default hostname as my own site, which protects me from the threats of subdomain takeovers.
Hash and deployment slots
Your deployment slots will also follow the same format as your production site. However, each of your deployment slots will contain a different set of hashes from the production site and other deployment slots. Your slots will always be created with the same scope as the production site.
Comparing the format for slots between the global (original) default hostnames and the unique (new) default hostnames, here is how the general format would look like:
As an example, if you create a site called “test” and a slot called “slot” in East US:
You will notice that the hashes from the production site and the deployment slot are different, and this is the expected behavior. If you created site called “test” with “Tenant Reuse” and then created a slot called “slot”, anyone within your tenant who creates the same resources with those names will also get the same hashes that correspond to “test” and “slot”.
How does the region in the unique default hostname work
The region in the unique default hostname would be based on the region where the site is located. Since the unique default hostname is now regionalized, you will be able to create a site called “test” in different regions. The site name however still must be regionally unique, which means that there can only be one site called “test” in East US regardless if they have different hash values.
You will notice that the region name is appended by a number (ie. “-01”). You should expect that this number could change at any time in the future, and you should not have any hard dependencies or hard code the number appended to the region.
How to create a web app with a unique default hostname?
You can create a web app with a unique default hostname through Azure Portal, API, or ARM. CLI is currently not supported. This can only be done during resource creation, meaning that you will not be able to update your pre-existing web apps to have a unique default hostname. You will have to decide during resource creation to create a site with a unique (new) default hostname or a global (original) default hostname format – it's one or the other.
Azure Portal
Any site created with a unique default hostname through Azure Portal will be created using the “Tenant Reuse” level (for more information, refer to section “How does the hash in the unique default hostname work”). Azure Portal will be fully deployed by June 7th, 2024.
If you would like to create a web app with a different scope for the hash, kindly use ARM or API.
To create a new web app with unique hostname on Azure Portal:
ARM or API
If you are creating a web app using ARM or API, you can use this method to deploy your web app with a unique default hostname. You can also select the scope you would like to create your hash with.
In your API or ARM request, you need to add the following property to your site properties in the payload.
For the different scope level for your hash, you can choose from:
Sample API Call
Ending Note
We will continue to support pre-existing web apps that were created with the original global default hostnames. However, we highly encourage all customers to start creating web apps with the unique default hostnames to protect your organization from the threats of subdomain takeovers.
Continue reading...
This feature is currently in Public Preview and is only available for web apps on multi-tenants. App Service Environment (ASE) resources are not supported. Functions and Logic Apps (Standard) are currently out of scope, but we have plans on supporting them soon, so stay tuned.
This feature would require you to “opt-in” to create a site with a unique default hostname. This means that when you create a site through the portal, you will need to select the option to enable the feature; Azure Portal will be fully deployed by June 7th, 2024. When you create a site through ARM, you will need to provide your deployment templates with new parameters. You will not be able to update pre-existing web apps to create unique default hostnames; unique default hostnames can only be opt-in during web app resource creation.
This article will go over the following:
- What are dangling DNS and subdomain takeover
- How the unique default hostname feature works
- How to create new web app with a unique default hostname
What are dangling DNS and subdomain takeover?
One of the most common scenarios for subdomain takeover is when a customer forgets to clear the DNS entries after deleting a pre-existing web causing dangling DNS. A bad actor could come in and create a web app with the same name and use the pre-existing DNS records to takeover domains because the web app will still have the same default hostname as the previously deleted one. You can learn more about dangling DNS and subdomain takeover here.
How does this feature work?
The unique default hostname will have a different format than the original global default hostname in two ways. The unique default hostname will include:
- A random hash appended to the web app name with a dash “-”
- A region name
Comparing the format between the global (original) default hostnames and the unique (new) default hostnames, here is how the general format would look like:
| | Global (Original) | Unique (New) |
| Default Hostname Format | <AppName>.azurewebsites.net | <AppName>-<RandomHash>.<Region>.azurewebsites.net |
| SCM Endpoint Format | <AppName>.scm.azurewebsites.net | <AppName>-<RandomHash>.<Region>.scm.azurewebsites.net |
As an example, if you create a site called “test” in East US:
| Site Name | test |
| Unique Default Hostname | test-a6gqaeashthkhkeu.eastus-01.azurewebsites.net |
| SCM Endpoint | test-a6gqae9sh1hkhk8u.scm.eastus-01.azurewebsites.net |
How does the hash in the unique default hostname work
The hash used for the unique default hostname would be a 16-character hash. This hash could be configured to a given “scope”, which ensures the degree of how unique you would like default hostname to be.
You can choose to generate the hash based on the following “scopes”:
- Tenant Reuse
- Subscription Reuse
- Resource Group Reuse
- No Reuse
So as an example, for my site called “test”, I could choose to generate a hash that could be shared across my subscription if I selected the “Subscription Reuse”. What this means is that anyone in my subscription who tries to create a web app called “test” in any region using the “Subscription Reuse” will end up with the same hash as I would. Anyone else outside of my subscription who tries to create a site name called “test” will not end up with the same hash as I would.
If your team tends to redeploy web apps in different environments for testing, it could be helpful to select a scope that is shared between environments. As an example, I have both Subscription AA (test subscription) and Subscription AB (production subscription) under Tenant A, and I tend to redeploy resources from Subscriptions AA to AB. What I should do is to deploy a site with the unique default hostname that uses the “Tenant Reuse” in Subscription AA because both subscriptions share the same tenant. Then when I need to delete and redeploy in Subscription AB, I should keep using Tenant Reuse. This ensures that the site I create will still have the exact same default hostname. More importantly, during the period that I try to delete and redeploy my resource, no one else outside of my tenant would be able to recreate another site with the exact same default hostname as my own site, which protects me from the threats of subdomain takeovers.
Hash and deployment slots
Your deployment slots will also follow the same format as your production site. However, each of your deployment slots will contain a different set of hashes from the production site and other deployment slots. Your slots will always be created with the same scope as the production site.
Comparing the format for slots between the global (original) default hostnames and the unique (new) default hostnames, here is how the general format would look like:
| | Global (Original) | Unique (New) |
| Default Hostname Format | <AppName>-<SlotName>.azurewebsites.net | <AppName>-<SlotName>-<RandomHash>.<Region>.azurewebsites.net |
| SCM Endpoint Format | <AppName>-<SlotName>.scm.azurewebsites.net | <AppName>-<SlotName>-<RandomHash>.<Region>.scm.azurewebsites.net |
As an example, if you create a site called “test” and a slot called “slot” in East US:
| Site Name | test (production site) | slot (deployment slot) |
| Unique Default Hostname | test-a6gqaeashthkhkeu.eastus-01.azurewebsites.net | test-slot-ekcda0qhg9em5yc9.eastus-01.azurewebsites.net |
| SCM Endpoint | test-a6gqae9sh1hkhk8u.scm.eastus-01.azurewebsites.net | test-slot-ekcda0qhg9em5yc9.scm.eastus-01.azurewebsites.net |
You will notice that the hashes from the production site and the deployment slot are different, and this is the expected behavior. If you created site called “test” with “Tenant Reuse” and then created a slot called “slot”, anyone within your tenant who creates the same resources with those names will also get the same hashes that correspond to “test” and “slot”.
How does the region in the unique default hostname work
The region in the unique default hostname would be based on the region where the site is located. Since the unique default hostname is now regionalized, you will be able to create a site called “test” in different regions. The site name however still must be regionally unique, which means that there can only be one site called “test” in East US regardless if they have different hash values.
You will notice that the region name is appended by a number (ie. “-01”). You should expect that this number could change at any time in the future, and you should not have any hard dependencies or hard code the number appended to the region.
How to create a web app with a unique default hostname?
You can create a web app with a unique default hostname through Azure Portal, API, or ARM. CLI is currently not supported. This can only be done during resource creation, meaning that you will not be able to update your pre-existing web apps to have a unique default hostname. You will have to decide during resource creation to create a site with a unique (new) default hostname or a global (original) default hostname format – it's one or the other.
Azure Portal
Any site created with a unique default hostname through Azure Portal will be created using the “Tenant Reuse” level (for more information, refer to section “How does the hash in the unique default hostname work”). Azure Portal will be fully deployed by June 7th, 2024.
If you would like to create a web app with a different scope for the hash, kindly use ARM or API.
To create a new web app with unique hostname on Azure Portal:
- Go to the Web App Create page
- Toggle option to enable “unique default hostname”
- Fill out the required fields and click “Review + create”
ARM or API
If you are creating a web app using ARM or API, you can use this method to deploy your web app with a unique default hostname. You can also select the scope you would like to create your hash with.
In your API or ARM request, you need to add the following property to your site properties in the payload.
"AutoGeneratedDomainNameLabelScope": "TenantReuse"
For the different scope level for your hash, you can choose from:
- TenantReuse
- SubscriptionReuse
- ResourceGroupReuse
- NoReuse
Sample API Call
Code:
PUT https://management.azure.com/subscriptions/<SUBSCRIPTIONID>/resourceGroups/<RGNAME>/providers/Microsoft.Web/sites/<SITENAME>?api-version=2022-03-01
{
"location": "Central US",
"kind": "app",
"properties": {
"serverFarmId": "<AppServicePlan",
"AutoGeneratedDomainNameLabelScope": "TenantReuse",
...
...
}
}Ending Note
We will continue to support pre-existing web apps that were created with the original global default hostnames. However, we highly encourage all customers to start creating web apps with the unique default hostnames to protect your organization from the threats of subdomain takeovers.
Continue reading...