Azure Web App hosting within the Azure App Service is an amazingly flexible product. As with any product, with great flexibility comes a plethora of configuration settings that could expose your application to more risk. In this post, I'll investigate settings and configurations that you should validate in your own applications to ensure you are as secure as possible.
Background
Azure App Service hosting can be used for .NET, .NET Core, Java, PHP, and other technologies. As such, there are a plethora of configuration options, including multiple methods to publish your application out to the App Service. This makes onboarding easy, but often leaves configuration elements that are skipped by administrators. Some of these settings could easily expose your application to a security risk.
Therefore, in this post, I am going to review settings in a manner that should be helpful regardless of the technology used in your application. It is designed to be an overview of the features as they exist today, August 5th, 2018, this information may be out of date in the future as Azure services change on a regular basis.
Application Settings
The first area to review is the Application Settings. These are accessed from your Web App in the Azure Portal and then select "Application Settings" from the blade menu.
General Settings
Under the general settings section, we have the ability to enable/disable features, by default a number of features are enabled but might not be needed for your application. The table below shows key elements that we often find misconfigured in application.
| Setting | Recommendation |
|---|---|
| .NET Framework Version | This should be set to the highest version possible. |
| PHP Version | Should be "Off" if not using PHP, otherwise highest supported version |
| Python | Should be "Off" if not using Python, otherwise highest supported version |
| Java | Should be "Off" if not using Java, otherwise, highest supported version |
The table above covers the general settings that are overlooked. The key consideration being the need to disable the functionality that you are not using. This protects your application in the case that a malicious file or other exploit be exercised should it leverage a different technology.
FTP Configuration
The last setting in the general section is worth noting. By default Web App's are configured to allow FTP & FTPS. At a minimum, it would be recommended to change this to require FTPS to secure the communications. However, it is my preference for sites that are not updated regularly to disable FTP entirely. This will ensure that your application is not accessible via FTP further protecting from unauthorized usage.
Default Documents
The default list of documents contains support for various technologies, including basic HTML content. I recommend removing all entries here except for those necessary for your technology of choice. For example, I leave default.aspx as the only entry for a default .NET Application. If you leave other files defined, and they are earlier in the list, simply dropping a file with that name in the root can overtake your homepage.
Backups
Although not directly a security configuration, proper backups are a critical component to ensure that you have a valid Disaster Recovery (DR) plan in place. Azure App Service provides a nice built-in feature that can take regular backups for you, the configuration is a breeze from the "backups" configuration setting on your Web App. We recommend for consistency always having this configured with a minimum of 1 week of rolling backups.
Monitoring Settings
After initial application creation, many people focus on just getting the configuration needed to deploy their application and don't explore the rest of the settings available. The monitoring section of configuration is an area often overlooked and one that contains a plethora of options that will allow you to manage/review activity to your application. Let's look at some of these settings.
Diagnostic Logs
This section is where you can enable various types of logging. The most critical option here is the "Web Server Logging." This feature, disabled by default, allows you to collect logging in the IIS format to track activity to your application. I strongly recommend that everyone enable this, either storing to the file system, or blob storage for a minimum of 30 days. With this information, if you do suffer an exploit, you can at least retrace the steps that the malicious user might have taken through your application.
The additional options in this section are more primarily focused on application development diagnostics and are often left "off,"
Summary
App Service hosting is great, but the true "turn-key" settings might leave you slightly exposed, I hope these quick tips were helpful.