Are you currently experiencing an attack?

Are you currently experiencing an attack?

AWS WAF: A Deep Dive, Part 2

When evaluating a WAF, an important consideration is how well it covers the applicable risks defined in the OWASP Top 10 list. OWASP describes this list as “a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.”

The first part of this series (AWS WAF: A Deep Dive, Part 1) covered the use cases for web application firewalls and their value to a software organization. It also discussed Amazon Web Services’ WAF offering, gave a high-level view of its feature set, and ended by talking about some of the challenges in getting started.

Now in Part 2, we’ll further evaluate AWS WAF, using the OWASP Top 10 as our guide. We’ll see how well it addresses specific threats, as well as the challenges or difficulties users might face in mitigating them using this security service. We’ll conclude with a discussion about mitigating the overall limitations of AWS’ offering.

Some AWS WAF Basics

Before getting started, there are a couple of key points to note about AWS WAF:

  • It uses Web Access Control Lists (ACLs) as its primary protection mechanism. These are composed of rules and rule groups that define the actual firewall logic.
  • It can only be employed to secure Amazon CloudFront distributions, API Gateway REST APIs, application load balancers (ALBs), and AWS AppSync GraphQL API endpoints. For example, you cannot use it to secure a web application running on an EC2 node unless you have an ALB handling request traffic.

AWS WAF and the OWASP Top 10

For each of the risks in the OWASP Top 10 list, we’ll discuss:

  • What the risk is
  • How AWS WAF can, or cannot, help to mitigate it
  • Important limitations to keep in mind

A01:2021 – Broken Access Control

Broken access control essentially means that a user or user-like entity is able to perform an action outside the scope of their assigned permissions. A basic example would be a standard user being able to access data and actions normally reserved for root or administrative users without being explicitly granted that access via a policy.

There are several possible mitigations depending on the context of the system being attacked, including: limiting CORS usage, deny-by-default access policy, strong logging, and short-lived JSON Web Tokens (JWT).

AWS WAF Mitigations

AWS WAF provides users with several managed rule sets that help address common vectors like CORS in its Core rule set (CRS) and baseline rule groups.

Limitations

Static rule definitions require users to enumerate all potential failure modes and attack vectors. Attacks beyond the scope of the managed rules, such as CORS, require manual rule creation. 

Access control breakdowns typically result in misconfigurations that occur in infrastructure beyond AWS WAF’s scope of control. Therefore, it has no visibility into whether a policy is correctly scoped.

Finally, users wanting to provide similar protections to workloads that don’t use the AWS frontend services mentioned earlier, will need to look elsewhere.

A02:2021 – Cryptographic Failure

Cryptographic failures relate to either the failure or lack of mechanisms to correctly protect (encrypt) data at rest or in transit. Since web traffic is ostensibly encrypted, WAFs typically inspect traffic after it has been terminated.

AWS WAF Mitigations

As mentioned, WAF inspection requires decrypted traffic, so any failure or substandard encryption implementation is outside the scope of a WAF. Certain patterns in HTTP requests might indicate attempts at accessing sensitive data, so you can use string matching via manual rule creation.

Limitations

Because of the limitation that generally applies to all WAFs, AWS WAF users will need to explore the use of additional tools to monitor and maintain encryption configuration. AWS Config is an option to detect if common cryptographic standards are being followed on relevant resources.

A03:2021 – Injection

Applications that do not validate and sanitize untrusted data inputs are vulnerable to injection attacks. SQL is a common target. If a database is allowed to accept unfiltered statements passed in from external queries, an attacker could gain access to, or even destroy, sensitive data.

AWS WAF Mitigations

AWS provides a specific managed rule group to deal with SQL attacks, including SQL injection. For more advanced cases, you can specify additional rules and custom string matches for known bad queries or blacklist specific IPs known to originate attacks.

Limitations

If an application depends on users being able to craft certain SQL queries, configuring the proper hierarchy and processing the order of rules so that the application can still function will require extensive manual work to craft an ACL with the correct functionality.

A04:2021 – Insecure Design

Insecure design is a subjective, high-level threat category that applies to the architecture of your entire system. To avoid potential attacks, engineering teams need to focus on strong development methodologies and processes as much as on their technical implementation.

AWS WAF Mitigations

Although a properly configured WAF can help mitigate some of the threats, it can never properly address a fundamentally insecure design.

Limitations

Like any other WAF product, AWS WAF can only provide specific technical functionality to mitigate threats.

A05:2021 – Security Misconfiguration

Security misconfiguration is another high-level threat category that has a potentially broad impact across a variety of systems and software. Arguably a sub-category of A04, a misconfiguration here typically implies specific technical issues such as misconfigured permissions, overly verbose logging, and default accounts/passwords still present.

AWS WAF Mitigations

Users who are already aware of systems susceptible to misconfiguration can implement rules that look for specific strings or request patterns that might target administrative interfaces or known vectors in certain web languages.

Limitations

AWS WAF requires you to be able to pre-emptively identify potential avenues of misconfiguration, as well as craft rules and rules processing logic that adequately protect your underlying systems. Properly addressing misconfiguration typically requires additional AWS services like AWS Config or AWS Systems Manager.

A06:2021 – Vulnerable and Outdated Components

Component vulnerabilities are one of the most prolific risks to modern web applications. Servers that have not been kept up to date with security patches, or applications that rely on dependencies with known vulnerabilities, make excellent vectors for compromise.

AWS WAF Mitigations

This is another category where a WAF will not be terribly effective without prior knowledge of potential vulnerabilities. The best mitigation strategy is more about culture and process. 

Having a DevOps and DevSecOps culture, and shifting security farther left in the software development lifecycle (SDLC), helps catch potential vulnerabilities much earlier in development and prevent them from making it into releases.

Limitations

Engineering teams will need to implement more holistic measures to deal with component vulnerabilities, as AWS WAF works best in addressing isolated, risk-accepted vulnerabilities.

A07:2021 – Identification and Authentication Failures

This threat vector revolves around user identity, authentication, and session management. Typical examples include allowing repeated failed login attempts, having a weak password policy, and exposing session details via a URL or query.

AWS WAF Mitigations

AWS WAF provides different approaches for dealing with attacks in this category. If hackers are attempting brute force login retries or path enumeration, users can implement a rate-based rule statement; this will limit the number of requests that can originate from the same IP in a given window of time. 

If a user account or token has been compromised, you can use string matching rules to blacklist requests containing either the token or account string.

Limitations

There are several limitations users should be aware of. With rate limiting, AWS WAF only performs a check every 30 seconds for the previous five minutes; a heavily resourced attacker could send a large number of attempts in that time. 

AWS WAF also can only block up to 10,000 IP addresses; if the attack is distributed, it may overwhelm this limit.

We’ve written previously about how to setup rate limiting with AWS and other competing cloud providers, and the weaknesses that they all share.

A08:2021 – Software and Data Integrity Failures

Integrity failures involve software and software infrastructure that fails to validate external sources for integrity. Commonly referred to as supply chain attacks, this threat can be particularly effective since it often originates from legitimate sources, having fundamentally compromised upstream providers of updates and source code.

AWS WAF Mitigations

Since integrity failures often occur along the same path as legitimate activity, it can be extremely difficult to configure a WAF to effectively mitigate it. 

AWS WAF users could implement string matching rules and IP blacklists once a threat has been identified, but this likely means a compromise has already occurred.

Limitations

AWS WAF does not provide dynamic configuration abilities to respond to these types of threats. You will need a multi-faceted approach with technology and process improvements to effectively protect your infrastructure.

A09:2021 – Security Logging and Monitoring Failures

This category is another type of misconfiguration that focuses on the operational infrastructure and mechanisms used by your applications. Effective security logging and monitoring allows security teams to quickly identify and respond to potential attacks and breaches. Poor logging and monitoring means attacks may go undetected for some time or, worse, are never detected at all.

AWS WAF Mitigations

In this category, AWS WAF itself is a potential vulnerability. Users need to make sure that it and the rest of the application stack all emit adequately detailed logs, and ideally push these to a central location that provides monitoring and alerting capabilities.

Limitations

It’s up to security teams to work with operations staff to ensure every component of a web application is configured to log security events correctly. Web application firewalls generally do not provide configuration monitoring capabilities.

A10:2021 – Server-Side Request Forgery

Server-side request forgeries (SSRF) occur when a user causes an application server to request some data or a resource from a URL without confirming the validity of what the user actually provided. This can cause the server or application to potentially send sensitive data to a third party, or allow untrusted code to execute remotely and provide persistent access to an attacker.

AWS WAF Mitigations

AWS WAF users can implement unique tokens in request headers and use string matching rules to check for the presence of those values. AWS also provides several rules in its Core rule set that specifically address SSRF attacks against EC2 instance metadata endpoints.

Limitations

AWS WAF will generally require you to develop your own logic for URL sanitization, as each application and service stack will have different requirements. Users will get more “bang for the buck” by ensuring the application logic itself properly sanitizes URL inputs.

Compensating for the Weaknesses of AWS WAF

AWS WAF certainly offers some protective features for web applications, but it isn’t a complete solution. We’ve previously discussed topics such as whether AWS WAF and AWS Shield are enough to secure your environment, cloud security and AWS, and even published how-to guides such as how to configure and use AWS WAF; throughout, we’ve shown that it’s important to know this service’s strengths and weaknesses. AWS WAF has several performance limitations, including a fixed scope of systems it can protect, and rule management is a manual and complex process.

Perhaps the worst overall limitation is one that you might have noticed as a common theme in the discussion above. Creating and managing rules for AWS not only requires a substantial and ongoing time commitment from IT staff, it also requires a high level of expertise to do it correctly and comprehensively. Falling short in this area can create potentially severe vulnerabilities.

A better approach is to use Reblaze, which is a complete web security solution; a cloud-native security platform that is fully integrated with AWS. Along with a next-gen WAF and multi-layer DDoS protection, it includes many features that AWS WAF and AWS Shield do not, including bot management, advanced rate limiting, API security, ATO (account takeover) prevention, and much more. Reblaze converts AWS WAF and AWS Shield into an automated and fully managed system. 

If your organization is using or considering AWS WAF, you should consider getting a demo of Reblaze to see all the options available to you.

In Part 3 of this series, we’ll continue to explore the deeper technical features of AWS WAF, and the potential challenges users might face when configuring it to deal with a broad spectrum of threats.

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.