RASP vs. WAF Comparison in Application Security

One thing that you learn in the technology space is that change is constant. Companies, solutions, and people who sit on their laurels can find themselves in a position of never-ending catch up. For security operations and application security professionals who rely exclusively on web application firewalls (WAFs), this should serve as a warning. Tethered to traditional signature-based security approaches, WAFs simply aren’t able to keep pace with the changes in the advanced threat landscape.

Enter runtime application security protection (RASP). While some application security professionals research using WAF VS RASP or erroneously believe RASP tools should replace their WAFs, they are mistaken. Don’t fall into that comparison trap. Instead, they should be used in conjunction with each other; they supplement each other to deliver a comprehensive application security solution.

What Is a WAF and How Does It Work?

Historically, WAFs were initially coined application firewalls and were used to control input, output, and access from applications or services. Largely a network-based firewall when it was first developed in the early 1990s, WAFs first entered the market as stand-alone solutions in the early 2000s. The open source project ModSecurity that was formed in 2002 made WAF technology more accessible and sought to better define business cases and rule sets. 

In a nutshell, a WAF is a signature-based product—which comes in appliance, VM, and cloud-based form factors—that is used to block web requests that look like attacks. A WAF, as an in-line network traffic and content inspection tool, looks at the protocol traffic to and from the end user to determine if any attack signatures are present. While a WAF analyzes traffic and/or user sessions to and from applications, it cannot see how that traffic is being processed within applications. Relying on a purely signature-based approach, if a WAF detects a signature hit, it may block the “attack” depending on how the WAF is setup.

Though additional capabilities are available in many WAFs, many organizations only deploy their WAFs in basic blocking mode to satisfy Payment Card Industry Data Security Standard (PCI DSS) compliance. So, what does this mean? If a signature is detected, the WAF will block it regardless if the attack could be successful or not. But here is the rub. This results in countless false positives that drain valuable time on the part of security operations and application security teams, who must expend valuable time tuning and recalibrating the WAF to ensure real application traffic is not being blocked.

What Is a RASP and How Does It Work?

RASP tools have been around for a few years. And while RASP and WAF tools see the HTTP request and response traffic, and in some cases signatures the traffic, this is where the similarities between WAF and RASP end. RASP takes application security the additional mile—and it is an important trek.

To begin, RASP takes the input and not only runs signatures on the input, but it also traces the input to a “sink” and determine if the input or detected attack string would successfully execute. As a result, RASP is much more accurate than WAF through the use of instrumentation of the application and the ability to trace detected attack strings all the way to a vulnerable sink. Further, because RASP solutions observe actual application behavior, they don’t require the recalibration of statistical and other models the way a WAF does.

The false positives that occur with WAF solutions are eliminated with RASP. But this isn’t all—false negatives (viz., threat misses) that occur with WAFs also are eliminated. Additionally, unlike a WAF that open the floodgates and inundate security operations and application security teams with alerts, the RASP delivers highly accurate and relevant alerts based on an application’s behavior versus predictions that may or may not prove true.

Comparing the Capabilities of RASP vs WAF

Understanding the difference between a RASP and WAF and how that translates into real-world threat scenarios is important. Consider the following scenario where a user wants to change their name on a website they frequently browse. They log into the web application and locate the form to change their name and submit a simple form to enter their name. It might look something like this: 

WAF

Here, a WAF would look at the input and see the “OR 1=1—" as a common SQL injection attack pattern and block the attack.

RASP

In contrast, a RASP extends the analysis further, examining the input string “name” parameter value and determining if there is an attack pattern. Accordingly, “OR 1=1--" is recognized as a common SQL injection attack pattern and flagged as a potential SQL injection attack. But the RASP does not stop there; it then follows the tainted data and examines the request at the “sink.” If the detected attack string (“OR 1=1—") ends up in a SQL execute command sink, an exception is identified, and the attack would be blocked.

But what happens if the attack is changed slightly. What happens if the attacker uses the same form and the attack resembles the below?

WAF

Similar to the previous example, the WAF examines the input and detects what looks like a Command injection attack and blocks it, even though we know from the previous example that the data never ends up being executed as a command. It is only used as part of a SQL execute. As a result, the attack would never succeed and the WAF action determined to be a false positive.

RASP

The RASP examines the input string “name” parameter and determines the input to be a potential command injection attack. It then traces the input to the “sink” and determines that the sink is an SQL execute command, which could never result in a successful command injection exploit. Unlike the WAF scenario, the RASP would allow the request and avoid the false positive of the WAF. This is just one way that RASP reduces false positives.

This is where a RASP can pay real dividends to overstretched security and application security teams. Only detecting real attacks or attempted exploits allows a RASP to eliminate the alert fatigue that comes with a WAF and ratchets up operational expenditures (CapEx).

Understanding the Role of Payload Testing in the WAF and RASP Comparison

Often when deciding between a WAF and RASP, security operations and application security professionals will elect to perform payload testing. This involves gathering lists of “payloads” that look like attacks, which are saved across Github and other repositories like Portswigger’s XSS Cheat Sheet or the Open Web Application Security Project (OWASP). These payloads are typically not maintained after they are initially created, and often have duplicated entries or there may just be wrong payloads in a list such as having XSS payloads in a command injection payload list.

Recognizing this is a common problem, Contrast Labs conducted an exhaustive review of some of the most commonly used payload lists and tools. Tools and payloads that were most often used included the following:

What was the setup?

So, how did Contrast Labs determine this list? First, we used our Java Agent with Webgoat v7.1—specifically the exact copy of WebGoat for our Bug Bounty program. Second, all rules were set to block mode and no other modifications or configurations were used. Then, we selected four of the most heavily attacked vulnerabilities:

• Cross-site scripting (XSS)
• SQL injection (SQLI)
• Command injection (CMDI)
• Path traversal

Fourth, we took all the payloads lists from the tools and repositories and utilized Burp Suite to send the payloads to our vulnerable WebGoat instance.

As a result of this testing, we captured three different results with the four different vulnerability types:

• Invalid/or duplicate. This was attributed if a payload was not a valid attack vector or was a duplicate of an attack vector already in the list. We determined the duplicates were detected during testing and but concluded they should be marked as invalid so not inflate the detected numbers.
• Detected and blocked. This category was used if an attack string was detected and blocked.
• Not Detected but worth watching. This was used if a payload was not detected or detected only as worth watching. Here the attack string was deemed valid but it would not have succeeded in an attack in WebGoat.

Evaluating the WAF and RASP Results

The results tell us a few things. First, there are a lot of duplicate and not valid “attack strings” in these payload lists. Examples include:

• “delete”
• “like”
• “as”

These three single words are listed as “payloads” in SecLists for generic SQL injection. These single words would never end up in a successful exploit, but they could be used by a bad actor fuzzing for a SQL injection point. In this case, they were marked as “Not valid” along with many others across all the tested payload lists.

Second, as expected, there is a lot of variation in validity of the payload lists—from 20% of XSS to 82% in the case of path traversal. Third, the detected attacks were all valid attacks that would have resulted in an exploit against the WebGoat test instance. Finally, payload lists for XSS and SQLi were acceptable, but CMDi and Path Traversal found them problematic. This likely can be attributed to the fact that those attacks are very technology specific or back-end OS dependent. Notwithstanding, the overall results were very good, and the attacks would all have resulted in action needing to be taken by a security operations center (SOC) or end user.

Where to Go with WAF and RASP

Observant readers will immediately note that a similar test was not run against a WAF. This was on purpose, as there is really no honest way to accurately compare the two. Only speculation is possible regarding the potential WAF results. Yet, there are capabilities that a WAF delivers that a RASP is unable to perform. For example, a RASP cannot detect attacks that are not valid or those that would not result in an actual exploit. Here, a WAF will “perform better” by blocking and detecting more attack strings, though this creates false positive noise that impacts the ability of the security operations and application security teams to focus on the threats that really matter.

The question for many security operations and application security professionals is not, “Should I use a WAF or RASP?” but rather “Why should I not use both?” The WAF and RASP are both critical pieces in the overall puzzle of stopping web attacks: front-end (WAF) and back-end (RASP) puzzle pieces are essential for teams that seeking comprehensive risk coverage.

To get started, security operations and application security teams need to ensure they are proactively managing risk and going beyond signature-based scanning. This requires that payload testing includes testing endpoints for vulnerability and results in much more precise and accurate alerting.

Organizations that do so reap two primary benefits. First, their security operations and application security teams can focus only on vulnerability risks that matter. As these teams are often overstretched due to the volume of alerts they receive, which are often false positives, the resulting productivity gains are critical. But just as importantly, by focusing on the threats that pose a true risk, security operations and application security teams become more effective in managing risk, reducing the likelihood that malicious threats will impact their organizations.