Introduction to Application Security and RASP
1.0 Chapter Overview
This chapter introduces the current state of application security, the basic concepts of RASP, its implementation principles and usage scenarios, along with a brief analysis of RASP’s advantages and disadvantages.
1.1 Current State of Application Security
Traditional application security protection (WAF) is deployed outside web applications, intercepting requests carrying attack signatures by analyzing traffic. WAF analyzes HTTP traffic before it reaches the application server, but detection methods based on traffic analysis can be easily bypassed. Judging attack attributes solely by analyzing HTTP request characteristics is relatively one-sided and can easily lead to misidentification of vulnerabilities, potentially causing devastating impacts on programs. Numerous web application attacks bypass WAFs, making optimization challenging.
Recent years’ high-risk CVEs indicate that vulnerabilities are primarily concentrated in various remote code executions, followed by file access (directory traversal, file uploads, and file reads, etc.), with unauthorized access vulnerabilities ranking third. Deserialization and command execution also account for a significant proportion. The distribution of major vulnerability types is shown in Figure 1-1 below.
Figure 1-1 Distribution of high-risk vulnerability attack types over the past five years
Data source: Alibaba Cloud High-Risk Vulnerability Database, accessed at: https://avd.aliyun.com/high-risk/list
Figure 1-2 Alibaba Cloud High-Risk Vulnerability Database
Among the vulnerabilities with significant impact are: Apache Log4j2 Remote Code Execution Vulnerability (CVE-2021-44228), SpringShell Remote Code Execution Vulnerability (CVE-2022-22965), and Confluence OGNL Remote Command Execution Vulnerability (CVE-2023-22515). Ranking first is the Apache Log4j2 Remote Code Execution Vulnerability, the most severe vulnerability in the past decade, with enormous impact due to its widespread use and simple exploitation.
1.2 What is RASP?
As web application attack methods become more complex, protection mechanisms based on request characteristics can no longer meet enterprise security needs. As early as 2014, Gartner introduced the term “Runtime application self-protection,” abbreviated as RASP, a new type of application security protection technology that “injects” protective functions into applications, integrating them seamlessly. By hooking a few critical functions, RASP monitors the internal state of the program during runtime in real-time. When suspicious behavior is detected, RASP accurately identifies attack events based on the current context and blocks them in real-time, enabling applications to self-protect without requiring manual intervention.
Figure 1-3 below illustrates the principle of RASP protecting against SQL injection.
Figure 1-3 Principle Diagram of RASP Protecting Against SQL Injection
RASP detects high-risk behaviors of web applications in real-time, improving detection accuracy through signature rules, sensitive method calls, contextual correlation, and data correlation analysis with other security products (such as HIDS and WAF). Compared to WAFs, RASP does not need to analyze massive request characteristics but focuses more on application behavior to detect known and unknown security threats. Additionally, in alert logs, RASP can precisely locate the line number of the vulnerable code, providing significant assistance in vulnerability reproduction and remediation.
1.3 What Can RASP Do?
- Defend Against Unknown Attacks
RASP focuses on sensitive behaviors of business operations. Unknown attacks often trigger a series of high-risk behaviors, such as command execution, file access, class loading, and sensitive information probes. RASP can always detect traces left by attacks.
- Vulnerability Localization
When reporting vulnerability attack information, RASP includes not only request context but also method parameters, return values, and call stacks of sensitive functions. This information can fully reproduce the attack path and method of the vulnerability.
-
Hot FixingRASP can apply virtual patches to applications, fixing vulnerabilities not yet addressed by official updates. Particularly for large, complex systems where updates and restarts are not permitted, its hot-fix mechanism can promptly stop vulnerability bleeding, significantly reducing vulnerability exposure time. By adding new function hooks and detection rules, businesses can achieve security reinforcement in a relatively short timeframe.
-
RASP empowers scanners to implement gray-box detection (IAST).
Based on RASP technology, it’s easy to extend into a gray-box scanner (IAST), enabling early detection in development and testing environments. This achieves two different functional uses within a single product.
- Mapping software supply chain attack risks
Taking Java as an example, RASP operates inside the JVM and can accurately obtain information about loaded JAR files (versions, paths, etc.), theoretically eliminating false positives and false negatives. Combined with third-party CVE vulnerability databases, it can assess the risk level of the current system. Compared to methods like scanning disk files, parsing POM files, or examining process-loaded files, this approach offers higher accuracy.
1.4 RASP vs WAF
Traditional WAFs primarily filter attack requests by analyzing traffic characteristics and intercepting requests carrying attack signatures. While WAFs can effectively filter out most malicious requests, they lack visibility into application runtime context, inevitably leading to some degree of false positives. Moreover, WAFs heavily rely on signature databases, and various evasion techniques make it difficult for signatures to cover all variations.
RASP’s main advantages over WAF include:
-
RASP operates within applications, integrating with them to access runtime context. It can precisely identify or intercept attacks based on runtime context or sensitive operations. Since RASP runs inside applications, with properly selected detection points, the payloads it captures are already decoded real payloads, reducing false negatives caused by imperfect WAF rules.
-
Unlike WAFs deployed outside applications, RASP works inside applications and can analyze both external and internal network traffic. By hooking various access points including HTTP requests, RPC, Socket, DNS, etc., RASP builds comprehensive context. When detecting sensitive behaviors, it reports contextual environment, attack payloads, stack traces together, greatly enhancing detection and traceability capabilities.
RASP possesses advantages that WAFs lack and is increasingly becoming standard in security defense systems. However, WAF remains a mature, fast-deployable security product suitable for large-scale deployment. RASP and WAF are complementary - they operate at different dimensions. The core difference is that RASP can more accurately intercept vulnerabilities (even zero-days), while WAF’s traffic-based mechanism cannot fully understand internal business logic and is more easily bypassed.
RASP’s problem-solving approach is less direct - it functions more like a vaccine, building immunity based on internal signals; whereas WAF is more like protective gear (masks/armor) that provides immediate defense by wrapping around applications. The two complement each other: WAF serves as the perimeter defense while RASP provides internal application protection, ensuring effective attack interception.
RASP and WAF are not replacements for each other - each excels in different business and security scenarios. For application protection, they collaboratively build dual-layer defense capabilities (boundary + intrinsic) to minimize risks of application intrusion, data breaches, and service unavailability.
Figure 1-4 illustrates the relationship between WAF/RASP cybersecurity products and application services.
Figure 1-4 Relationship between WAF/RASP cybersecurity products and application services
1.5 Challenges of RASP
Despite its advantages, RASP’s implementation also introduces several challenges that result in high development costs and adoption difficulties:
- Significant impact on business operationsSince the detection process code needs to be embedded into business code, this introduces a significant amount of logic unrelated to the business process during runtime, thereby increasing the response time of business requests. Compared with more mature cybersecurity products like WAF and HIDS, from an isolation level perspective, RASP runs within the host Java process with the lowest isolation level, only separated from the business by class loaders, as shown in Figure 1-5. If RASP itself encounters issues such as deadlocks, null pointers, or memory leaks, it will directly impact the business.
Figure 1-5 Isolation levels of WAF, HIDS, and RASP cybersecurity products relative to application services
- Development Cost Issues
For different programming languages, the underlying implementations of RASP vary. Each requires specialized development based on language-specific features and demands developers to have a deep understanding of the language’s runtime mechanisms and internal implementations. Generally, it is challenging for a programmer to master more than two mainstream languages (including Java, PHP, Python, C++, Golang, and Node.js), which implies higher research, development, and testing costs.
- Deployment and Maintenance Issues
Taking Java RASP as an example, there are two deployment methods: one requires specifying the Agent location before startup, while the other allows deployment via Attach during runtime. However, both approaches have their own problems. Specifying the Agent location before startup means service restarts are needed during deployment, affecting normal business operations. When deploying via Attach during runtime, since the Java process is already running, RASP initialization—especially bytecode modification—significantly impacts business performance. Additionally, once the Agent is loaded, it cannot be unloaded, and feature updates still depend on restarting the business process.
1.5 Basic Principles of RASP Vulnerability Detection
Currently, the primary focus of RASP remains Java RASP. Its implementation involves writing a Java Agent that calls the Instrumentation API to insert security detection code into critical functions of the application. As shown in Figure 1-6, RASP adds multiple monitoring methods along the request call chain and saves parameters to the request’s context environment. When sensitive operations are executed, it comprehensively determines whether it is a vulnerability attack by analyzing the context environment, call stack, and sensitive operation parameters.
Figure 1-6 Java RASP Context Correlation and Vulnerability Detection
1.6 Chapter Summary
This chapter primarily introduced the main distribution of application security vulnerabilities, the technical foundation of Java RASP, and the principles of vulnerability detection. It also discussed the advantages of RASP over other security products and the challenges in current RASP deployment practices. This chapter provided only an overview of RASP usage scenarios; subsequent chapters will delve into the technical details.