Security Best Practices for Azure App Service Web Apps, Part 1

This post was written by Piyush Mittal. Microsoft’s Azure App Service is a fully managed Platform as a Service for developers that provides features and frameworks to quickly and easily build apps for any platform and any device. In spite of its ease of use, developers still need to keep security in mind because Azure […]

Microsoft’s Azure App Service is a fully managed Platform as a Service for developers that provides features and frameworks to quickly and easily build apps for any platform and any device. In spite of its ease of use, developers still need to keep security in mind because Azure will not take care of every aspect of security. This post is the first in a short series of articles from Intel Security’s Foundstone Professional Services that offers advice for securing Azure App Service Web app development.

Developers can create four application types using the Azure App Service:

Azure App Service Web Apps take care of the infrastructure and its security. The developer needs to focus only on the application code. Azure App Service is different from typical cloud scenarios in which developers set up their own servers in the cloud, install their own web applications, and take full responsibility for performance and security. With Azure App Service Web Apps, Microsoft owns and manages the infrastructure. The developers need only ensure the security of their application code. Both approaches has their merits.

When a web application is created using Azure App Service, it is assigned to a subdomain of azurewebsites.net. For example, if the app name is Demo, the URL is demo.azurewebsites.net. By default, Azure enables HTTPS with a wildcard certificate assigned to the *.azurewebsites.net domain. There creates multiple security issues:

A phishing attack can be easily carried out by creating similar-looking web application and domain name, for example, an attacker could create the malicious web app demo1.azurewebsites.net, which is similar to the legitimate name demo.azurewebsites.net. Because the web application is assigned to a subdomain of azurewebsites.net, the name of the malicious application looks very convincing and hard to differentiate from the original name unless one looks very closely.

If the DNS record for *.azurewebsites.net is entered by mistake or through DNS cache poisoning, then the application will be adversely affected.

The wildcard certificate creates more headaches for the developer because they need to ensure the path and domain of cookies are properly constrained.

The certificate is controlled by Microsoft. Thus for any certificate-related errors—such as expiration, strong or weak signing algorithms, trusted or untrusted certificate signing authorities, or certificates not self-signed—the developer will be dependent on Microsoft. Because the certificate is a wild card, extended validation of certificates can’t be enforced, which is preferred for financial applications.

Apart from security issues, most organizations want their customers to see a custom domain name instead a subdomain of azurewebsites.net. Thus it is necessary to create a custom domain name and get a certificate for that domain. Do not use self-signed certificates, rather buy one from a trusted certificate authority. Consider following while buying a certificate for a web app:

The certificate should be signed using a strong signing algorithm such as SHA-256.

The certificate should be valid and not expired.

For financial and other sensitive applications, it is best to have an extended validation for the certificate.

A custom domain name is not available with Microsoft’s free pricing plan, one of five plans. It is available with the other four. A custom domain name with HTTPS is available with the standard and premium pricing plans. To ensure the use of HTTPS, we recommend choosing either the standard or premium pricing plans when creating a web application with Azure App Service. (Microsoft has tie-in with GoDaddy to offer a custom domain name and a certificate from the Azure portal. Or you can buy a custom domain name and certificate from another domain registrar and use it with an Azure web app.)

For custom domain names purchased outside of Microsoft, follow these steps to configure it in the Azure portal:

A new frame will open on the right side. Click on “Bring external domains.”

Note the IP address located at the bottom. Go to your domain registrar website and create DNS entries using this IP address. It can take some time for the changes to propagate, depending on your DNS provider.

In the “Domain Names” text box, enter the custom domain name you bought from the domain registrar.

Save the changes.

Click on “Upload certificate.”

Locate and upload your .pfx certificate file.

Under “SSL bindings,” select the domain name to secure with SSL, and the certificate to use.

Save the changes.

You should be able to access the web app using your custom domain name over HTTPS.

For more details on how to set up a custom domain name and its certificate, follow these links from Microsoft: