RASP vs WAF

Attacks against web applications are increasing, especially automated ones. These web apps are exposed to the Internet, making them an easy target, and often act as a gatekeeper to valuable data or functionality.

Protecting web applications is a critical component of any organization’s cybersecurity strategy, and two of the most commonly used solutions for securing these applications are the web application firewall (WAF) and Runtime application self-protection (RASP). Knowing how these solutions work, how they complement one another, and what their pros and cons are is essential to identifying and blocking web application attacks.

What is a Web Application Firewall (WAF)

A web application firewall (WAF) is the original solution for protecting web applications against attack. A WAF is deployed at the network layer and provides protection to an organization’s entire suite of web applications.

WAFs can use a few different techniques to identify and respond to threats to web applications. WAFs will have a library of signatures used to detect known threats to web applications. These signature libraries are often complemented by anomaly detection that helps to identify abnormal web requests and responses that could be indicative of an attack.

The goal of a web application firewall is to provide generalized protection to all of an organization’s Internet-facing web applications. While WAFs can be tuned to provide individualized protection to different web apps, they can only observe and make decisions based upon the data visible to them within network traffic.

What is Runtime application self-protection (RASP)

Runtime application self-protection (RASP) solutions are designed to provide more targeted protection to applications. Instead of protecting all of an organization’s web applications as a whole, RASP monitors and secures a single application.

RASP works by performing introspection on a particular application. By monitoring the inputs, outputs, and behavior of an application, RASP can identify even novel attacks based on how they impact the behavior of the targeted application. Runtime application self-protection  is designed to provide very targeted, granular protection to an application. By using introspection, RASP can detect unique threats; however, Runtime application self-protection must be run on the same device as the application itself.

Comparing WAF vs RASP

WAF and RASP solutions are both designed to provide protection to web applications against cyber threats. However, the two solutions accomplish this goal in very different ways.

WAFs are designed to provide generalized protection across an organization’s entire web application infrastructure. They have the ability to catch and block attacks early in their lifecycles but can only do so by monitoring web traffic. Without visibility into the applications that they protect, WAFs can miss some threats, but the attacks that they do catch never reach the targeted application.

RASP, on the other hand, is designed to provide very individualized protection to an application. By monitoring every aspect of an application’s execution, RASP can detect even unknown attacks based on their impacts to the protected application. However, RASP must be run on-device, which can have impacts on overhead and application performance.

As mentioned above, WAF and RASP are complementary solutions for application security, not competitive ones. WAF provides a first line of defense, filtering out many threats to web applications before they even reach the target application. RASP then uses the context provided by deep visibility into these applications to identify and block attacks that slip by the WAF. This combination minimizes the impact of easily-detectable threats while also providing protection against more sophisticated attacks.

Going Beyond WAF to WAAP

The combination of WAF and RASP is a good one largely because RASP has the ability to identify and block the threats that WAFs miss. WAFs are a legacy solution to application security that often generate large numbers of false positives and false negatives due to their limited ability to identify threats based solely on network traffic.

Protecting web applications against modern threats requires going beyond supplementing WAFs with RASP to replacing them entirely with a modern solution. The next generation of the WAF is automated Web Application and API Protection (WAAP).

WAAP solutions acknowledge the fact that companies are increasingly exposing web application programming interfaces (APIs) to the Internet. While these APIs have many of the same capabilities as traditional web applications, they work in different ways and have unique security requirements. WAAP solutions provide comprehensive protection for web applications and APIs alike.

Not so long ago I was researching the different ways to secure a web application from hackers and other bad guys. Accidentally I stumbled upon a new technology in this field called RASP. The RASP stands for Runtime application self-protection. The technology looks quite promising and concentrated on the protection of an application from the inside. This aspect of RASP is quite opposite to other well-known approaches to the application security, e.g WAF or IDS/IPS. Let’s quickly revise the basic info about these approaches.

IPS/IDS

The IPS/IDS is the oldest technology among mentioned, and it has already proved to be useful. The main idea of the IPS/IDS is that they sit on the network, between your app and the client and monitor the network traffic for the sights of malicious data. The other useful function of such systems is a DDoS attacks prevention. IPS/IDS can be present both: hardware and software forms.

The main drawbacks of such systems

• They struggle to work with encrypted traffic (e.g. HTTPS);
• They mostly perform the simplest checks and perform no behavioural analysis and thus would not help with e.g bot detection;
• They are mostly written in C/C++ and have middle-to-big codebases, so they are hard to extend.

Well-known software systems of such a type are:

• Snort
• Suricata
• Zeek (the newest one among these)

WAF

The WAF stands for Web application firewall, and it is usually just OSI Level 7 application which addresses the IPS/IDS issues with HTTPS and extensibility. Usually, WAF can provide the same functionality as an IPS/IDS system, however it will have a poorer performance characteristics and support a lot less protocols that Enterprise level IPS/IDS.

The WAF basic functionality includes:

The WAF is a good fit to cover the holes left by the IPS/IDS, however you would still pay the cost of the one more agent between a client, and your web app (network round-trip cost, content analysis cost and so on). There a lot of open-source WAF out there. The AWS WAF may serve as an example of an WAF as a Service.

RASP

Here RASP comes to the rescue. The main idea of RASP is that all the application protection logic is directly integrated into your program. In such a way RASP eliminates at least part of the WAF performance impact and, also get access to your app intrinsics which can help with vulnerable code-path determination and access prevention for only specific clients/actions.

Currently, open-source RASP solutions exist only for Java and PHP (at least I have found only this one). With Java, for example, to integrate the RASP into application the java agents and thus code instrumentation is used.

The code instrumentation in Java basically allows the java agent to intercept any method calls and object interactions and gives RASP agent the ability to monitor and block any actions that happen in the code.

Nowadays RASP solutions can deal with XSS, CSRF, SQL injection and other well-known attacks, however the field is quite new, so there is no strong guaranties that RASP will block all the well-known attacks.

The main drawback of RASP from Java perspective is an agent usage. A lot of enterprise application already use some agents for things other than security and when you add many agents to your application things can get messy, agents can conflict and crash the JVM.