Are you currently experiencing an attack?

Are you currently experiencing an attack?

Azure WAF: A Deep Dive, Part 2

In today’s threat environment, a WAF (Web Application Firewall) must be able to protect against a wide variety of threats. A well-known list of these is maintained by the Open Web Application Security Project, known as the OWASP Top 10

This list is not comprehensive, nor is it meant to be. (OWASP says it is meant for “standard awareness,” to raise public understanding.) However, when evaluating a modern WAAP (Web Application and API Protection) solution, it’s a useful place to start.

In the previous article in this series (Azure WAF: A Deep Dive: Part 1), we gave a high-level overview of Microsoft’s primary service for web application security. We discussed its core rule sets, its provisions for custom rules, and its capabilities for traffic monitoring and reporting.

Now in Part 2, we’ll continue our exploration of this tool. We’ll go through the OWASP Top 10, and see Azure WAF’s strengths and limitations for addressing each one. Users of Microsoft’s cloud service need a robust web application firewall for Azure; below, we discuss whether or not Microsoft’s native WAF service is an optimal choice. 

A01: Broken Access Control

At the top of OWASP’s threat list is Broken Access Control. When access controls are compromised, users or entities impersonating users are able to take action that is not within their authority. Sensitive data could be leaked, altered, or deleted without permission, or an unintended business function could be carried out beyond the user’s limits.

Azure WAF’s capabilities and limitations

By its nature, this threat is outside of the scope of a traditional WAF. However, a modern WAF that uses Machine Learning and behavioral analysis can be an effective part of an organizations’ defenses against it.

Unfortunately, Azure WAF does not fall into this category, and it cannot do much against this threat.

Admins can (and should) take other steps to mitigate this risk, such as limiting the use of CORS, using a deny-by-default access policy or strong logging, and implementing short-lived JSON Web Tokens (JWTs). But Microsoft’s service will not be very relevant here.

A02: Cryptographic Failure

An inability to properly safeguard (encrypt) data in transit or at rest is referred to as cryptographic failure. Although the widespread adoption of HTTPS has reduced the frequency of this vulnerability, cryptographic failure is still a significant risk today. HTTPS is not yet omnipresent, and other protocols such as SMTP and FTP are still widely used; meanwhile, there are still reports of breaches where unencrypted data was discovered and exfiltrated.

Azure WAF’s capabilities and limitations

Azure WAF’s core rule set includes rules for cryptographic failures. However, inadequate encryption falls outside the purview of a WAF, because WAF examination is performed after the data has been decrypted. Admins are mostly limited to string matching, and manually creating rules to identify patterns in HTTP requests that might represent attempts to access sensitive data.

Users of Azure WAF will need to investigate extra tools to monitor and maintain their encryption setup in the context of these limitations. For example, you can use Microsoft Defender for Cloud to see if the right cryptographic procedures are being used with the right resources.

A03: Injection

Injection attacks can target applications that trust data inputs without validating them. Databases are a popular target for this; attackers who successfully inject SQL can read or even delete sensitive data, if an application accepts unfiltered inputs from external sources.

Azure WAF’s capabilities and limitations

Microsoft offers a managed rule group specifically to counteract SQL injection (SQLi). For more complex situations, you can define extra criteria, create custom string matches for known problematic requests, or ban particular IPs that are known to be attack originators.

Despite this, Microsoft implicitly acknowledges that Azure WAF alone does not provide complete protection, because it offers additional services like Azure SQL Database Advanced Threat Protection for this purpose.

Further, SQLi is only one type among many in the broader category of code injection attacks. Admins who use Azure WAF need to manually implement and maintain security rulesets to address the others.

A04: Insecure Design

This category of risks includes vulnerabilities that are inherent to a system’s design, as opposed to security implementation. In other words, even if all security measures were implemented perfectly, these problems would remain.

Azure WAF’s capabilities and limitations

A traditional WAF is not meant to mitigate the effects of an unsafe design, and Azure WAF does not address this either. Although some non-traditional threat detection techniques can work here–for example, user entity and behavioral analysis (UEBA) can be used to distinguish legitimate users from hostile traffic sources–Azure WAF does not include them.

A05: Security Misconfiguration

Another high-level threat category with potentially broad impact is security misconfiguration. Examples include incorrectly configured permissions, error messages that contain stack traces or other sensitive information, and the continued use of default accounts and passwords.

Azure WAF’s capabilities and limitations

Azure WAF does not provide specific capabilities for this potential problem. Admins who are already aware of vulnerable systems can develop filters to scan requests for particular strings or request patterns that may exploit administrative endpoints or known vectors in particular software languages. They will probably also need to use several other services, such as Azure Front Door, Azure API Management, Microsoft Sentinel, or Microsoft Defender for Cloud.

A06: Vulnerable and Outdated Components

Some of the most pervasive threats to modern online applications are due to vulnerabilities of outdated components. Unpatched servers, software with known vulnerabilities, and other problematic dependencies are all potential avenues for system compromise.

Azure WAF’s capabilities and limitations

Without prior awareness of potential vulnerabilities, traditional WAFs such as Azure’s are not very successful in mitigating this threat.

The ideal mitigation plan begins with procedure and culture. Adopting DevOps and DevSecOps in the development lifecycle makes it easier to identify potential vulnerabilities early. Software development teams must shift security left, and organizations should consider adopting a web security solution that fully supports DevOps and DevSecOps.

A07: Identification and Authentication Failures

The user’s identity, authentication, and session management are the focal points of this attack vector. Common examples here are permitting recurrently unsuccessful login attempts, implementing a weak password policy, and disclosing session information via a URL or query.

Azure WAF’s capabilities and limitations

Robust rate limiting is a necessity for protecting against this risk. Indeed, rate limiting is a vital part of web security overall; for example, it’s an important part of ATO (account takeover) prevention

Unfortunately, Azure WAF doesn’t have inherent rate-limiting capabilities. To implement rate limiting, admins need to integrate Azure WAF with Azure Front Door and create custom rules. By doing this, the number of requests from the same IP in a certain period of time will be restricted. There are also string matching rules to block requests containing either a token or account string that have been compromised.

However, even these approaches will be insufficient in many situations. For example, it’s common for attackers to rotate IP addresses during brute-force attacks, in order to evade detection. 

For more information on obtaining effective rate limiting capabilities, see our article on rate limiting in the cloud.

A08: Software and Data Integrity Failures

This is a large category of potential risks. A software integrity failure (also known as a software supply chain attack) occurs when a system relies on plugins, libraries, modules, etc., from an external source that is compromised. Data integrity refers to the protection of objects or data that are encoded or serialized into structures; a failure here means that attackers are able to see, and potentially modify, sensitive data.

Azure WAF’s capabilities and limitations

It can be quite challenging to set up a WAF to successfully reduce integrity failures because they frequently follow the same path as authorized activities.

Azure WAF doesn’t provide dynamic changes for these types of attacks. Once a danger has been found, users of Azure WAF could apply string matching rules and IP blacklists, but this most likely indicates a compromise has already taken place.

To properly defend your infrastructure, admins need to take a holistic approach that incorporates process and technology upgrades. Additionally, adopting a fully managed security solution can ensure that whenever new threats arise, the solution’s security posture is upgraded immediately and automatically.

A09: Security Logging and Monitoring Failures

Logging and monitoring are essential components of web security. When an incident occurs, the security solution must generate detailed logs, and ideally, forward them to a centralized place while alerting essential personnel. If a security team is not alerted and equipped with sufficiently detailed information to diagnose and mitigate the problem immediately, this greatly increases the potential damage from the attack. 

Azure WAF’s capabilities and limitations

Although real-time monitoring and control of traffic is essential for a solid security posture, Azure WAF was not built for this purpose. Microsoft provides Azure Monitor for this, but it has many limitations. Real time data is not available, data cannot be stored indefinitely, and queries are limited to only 30 days of data at a time.

Real-time traffic monitoring and control is available to Azure users, but not through its native tools alone. For a more in-depth exploration of this topic, see our article on traffic logging and monitoring in the cloud.

A10: Server-Side Request Forgery

In a server-side request forgery (SSRF), a user tricks an application server into making a request to an arbitrary URL without verifying the authenticity of the user’s input. This could lead to the server or application sending private information to an unauthorized recipient; or it could permit the remote execution of malicious code, giving the attacker unrestricted access to the system. 

Azure WAF’s capabilities and limitations

Azure WAF can include special tokens in the headers of incoming requests, then utilize string matching rules to make sure those tokens are present. In addition, the Azure Core rule set includes additional rules designed to protect against SSRF assaults.

However, Azure WAF’s core rule set doesn’t provide a rule to restrict access to a virtual machine’s metadata service, so custom rules are necessary. Admins will also need to create their own logic for URL sanitization to work with Azure WAF, as the needs of each application and service stack are unique.

Compensating for the shortcomings of Azure WAF

Azure WAF provides some security for websites and workloads, but it isn’t a comprehensive answer. We’ve stressed the significance of understanding the service’s advantages and disadvantages; the number of systems that may be protected by Azure WAF is limited, and managing its rules is a complex, time-consuming process. Further, users need to integrate other Azure services such as Front Door, Application Gateway, API Management, and Azure Application Gateway Ingress Controller. 

Overall, Azure WAF requires a dedicated team of IT professionals with specialized knowledge and experience. Even then, some potential vulnerabilities will not be fully addressed.

Azure’s native security tools are not the only option for users of Microsoft’s cloud platform. Reblaze is a comprehensive web security solution that is fully integrated with Azure, and offers many capabilities that Azure itself does not. More information about Reblaze is available here.

In the next (and final) article in this series, we’ll continue our deep dive into Azure WAF, including discussions of implementation, tuning, and diagnostics. Stay tuned!

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.