Top 5 Ways to Secure Your Azure Web App
Make Security Your New Year’s Resolution
2020 has been a tough year for many, including anyone using this extremely popular infrastructure-monitoring software. You may be wondering what you can do as a software developer to secure your web application on Azure. Well, good news! I have five easy suggestions for you to implement to take your security to the next level. Better yet, you can implement them right now.
Web Application Firewall
This feature from Microsoft is ridiculously simple to deploy (single-click), offers protection for the top ten Open Web Application Security Project (OWASP) vulnerabilities, and allows customized rules to meet any security requirements for your applications.
Here are some of the best benefits and features the WAF offers:
- Protects web applications from vulnerabilities and attacks without modifying the backend code.
- Protects multiple web applications at the same time. An instance of Application Gateway can host up to 40 websites that are protected by a Web Application Firewall.
- Allows the creation of custom WAF policies for sites behind the same WAF
- Protects web apps from malicious bots via the IP Reputation ruleset (preview)
- Provides SQL-injection protection.
- Offers cross-site scripting protection.
- Protects against other common web attacks, such as command injection, HTTP request smuggling, HTTP-response splitting, and remote-file inclusion.
- Provides protection against crawlers and scanners.
- Protects your applications from bots with the bot mitigation ruleset. (preview) There’s a cost with this feature, but the number of included features and peace of mind are well worth it.
SQL Injection Attacks
SQL injection attacks occur when input data from something like a user interface gets added to a SQL statement. These attacks can do all sorts of exciting things to your database, from CRUD operations to admin operations on the database.
Here’s an example of how this may show up in a codebase:
At first glance, this may seem relatively benign. But that last part—where the userName parameter is concatenated to the command text—is a giant security red flag. Since SQL will execute that statement, it would be possible to append more SQL commands like updating the account balance, deleting records, or even returning more data from the database, including sensitive data.
Plenty of examples are available on the internet of the different ways this vulnerability can unfold. But what matters most is how to defend against it. This, it turns out, is simple. Use parameterized queries. Here’s how our original example updated would look:
What happens at this point is if an attacker decided to send in this value:
SQL will execute that and match that input literally as one string and find no matches, whereas in the example above it would return every account balance in the database.
Clean your SQL Database IP Whitelist
Chances are if you have an SQL Database in Azure, you have whitelisted IP addresses to allow direct database access via SSMS. Now is a great time to review your whitelisted IP’s and remove any unknown ones. You can take this one step further and add change-control processes to review the whitelists every X days.
HTTPS Only & TLS Version
Review your web applications’ HTTPS and TLS versions. There’s no reason not to have it set to HTTPS-only and TLS 1.2. Review these settings for all your web applications and enable them.
FTP Access
This is enabled by default when creating a web application on Azure. Another small but effective security improvement can be gained by disabling this feature if no one needs access. If your developers are publishing Web Applications to Azure via Visual Studio, then change this to FTPS and look into implementing a CI/CD pipeline to eliminate manual deployments. Finally, if you need help with CI/CD implementations, Anexinet has the in-house expertise to assist you. Please don’t hesitate to reach out to us with any questions. We’d love to help you get started.
Related Content
Share on 
