WAF and RASP:
Raising the bar for application protection

Introduction

Do all application attack attempts merit an equal alarm sound? Or, should “successful application attacks” merit a higher alarm? If that sounds like a no-brainer, then how can we sift through the attack noise and distinguish what is important and relevant to the security of our said application? What is an attack irrelevant to our said application?

This ebook is intended to provide some light reading on two technologies: Web Application Firewall (WAF) - pervasive in use in many networks across companies of all sizes and sectors; and Runtime Application Self Protection (RASP) technology - not as pervasive, but certainly more effective in sounding the right alarm, at the right time, for the successful attacks.

To understand the two technologies and why they are better together, let’s start from the beginning.

However, WAF also have limitations:

Brief use cases and limitations of WAF and RASP:

RASP: DEEPER PROTECTION WITH RUNTIME ANALYSIS

Runtime Application Self-Protection (RASP) complements WAFs by providing deeper application security from within. Think of RASP as a zero friction agent for production applications. It automatically hardens the runtime, the libraries, the open source software, and the app server, mitigating top vulnerability classes and stopping zero day exploits.

Here’s how RASP offers a distinct advantage:

However, RASP also presents some challenges:

The power of combining WAF and RASP:

Contrast Security’s statistics highlight a critical point: over 180,000 attacks bypass WAFs every week but are successfully blocked by the Contrast Protect RASP*. This demonstrates the limitations of relying solely on WAFs.

By combining WAFs with RASP, organizations can achieve a layered defense:

This layered approach offers several benefits:

TWO EXAMPLES

The Deserialization Attacks Example

WAF limitations and how Contrast Security’s RASP does it better

Deserialization attacks exploit a fundamental process within many applications. Applications often serialize data – converting objects into a format suitable for storage or transmission. Later, this data is deserialized back into objects for use by the application. Attackers can craft malicious payloads that, when deserialized, trigger unexpected or harmful actions within the application.

• The Challenge for WAFs:

WAFs primarily analyze the content of incoming requests. They might spot an unusually structured data payload, but often lack the context to understand how an application will process that data during deserialization. This means attacks that exploit application logic flaws in the deserialization process can slip through a WAF’s defenses.

• Real-World Example:

An attacker might craft a payload that, when deserialized, executes arbitrary code on the server (remote code execution). A WAF, analyzing the payload itself, might see nothing inherently malicious. It wouldn’t understand that the deserialization process would lead to the dangerous execution of attacker-supplied code.

Understanding the nature of a serialized object is only possible within the application. Only there is the content revealed and can be analyzed based on its true nature and its usage by the application. The instrumentation-based approach provides:

• Runtime Insight:

Contrast Protect operates within the application, monitoring its behavior at runtime. During deserialization, it observes how the data is processed – where it flows within the application and what actions it influences.

• Behavioral Anomaly Detection:

If the deserialized data triggers suspicious or unexpected actions, Contrast Protect recognizes these as potential attacks, blocking the request from causing further harm, and alerting security teams.

• Clean Exception Handling:

Contrast Protect can neatly integrate with the application’s error handling. If an attack is detected, it generates an exception, just like the application would for invalid input. This smoothly halts the abnormal usage, allowing the application to respond gracefully.

TWO EXAMPLES

The Log4Shell Example

The widespread Log4Shell vulnerability (2021) was a prime example. Attackers exploited a weakness in the popular logging library to inject malicious payloads that could take control of systems.

• WAF Limitations:

Until specific signatures were released, WAFs had little chance of stopping Log4Shell attacks.

• RASP Advantage:

Contrast Protect had defenses in place since 2018. Its dataflow analysis capabilities allowed it to identify the abnormal Log4Shell payload behavior during execution, preventing exploitation even before the vulnerability became public knowledge.

What security issues did the Log4Shell vulnerability expose?

Log4j exposed many things when it comes to security issues:

• Organizations struggled (and are still struggling) to find where Log4j was used. They do not have accurate asset management or Software Bills of Materials (SBOMs) of their systems to provide them with the ability to quickly identify problem areas. 
• Once organizations identified all their Log4j instances, they were not sure where to start to upgrade, and in most cases found themselves waiting on vendor to upgrade the systems first. 
• Only 50% of Log4j has been updated in one year's time. It is still hard to manage third party libraries even when we know there are egregious and critical vulnerabilities. 
• The biggest security exposure was the fact that most organizations have ZERO projection when a zero day is released [up until] when they can patch it. Even patching a WAF after a couple of days if minimally effective if it can or already has been bypassed. Organizations must protect their applications from these unknown risks through the use of runtime protections. 

"Given that the Log4j library is used in close to two-thirds of Java applications ... there is no reason for attackers to stop targeting it. They’ll be able to successfully exploit the vulnerability in many cases."

- David Lindner, CISO at Contrast Security

Conclusion

Most security teams see Web Application Firewall as a valuable security tool. However, as guardians of the security of our applications and indeed as guardians of our brand, reputation and business revenue, we need to understand that a WAF might not be enough to detect and stop successful attacks.

A Web Application Firewall can watch data that goes over the network, but its architecture does not enable them to see how that data is actually used. As a result, they sound an equal alarm for all attack attempts without raising the importance for attacks that could actually work. This wastes human effort on investigating issues that don’t matter, and results in constant manual tuning or auto-tuning where success depends on information that WAF’s simply do not have.

RASP provides a more effective application attack protection derived from actual monitoring and analysis of the application behavior and context everytime the application is used. By doing so, RASP tools control the application execution, detect vulnerabilities, and prevent real-time attacks that exploit vulnerabilities inside that application – without human intervention.

By combining WAF and RASP, organizations can achieve a more comprehensive and future-proof application security posture, significantly reducing the risk of successful cyberattacks.