Application protection uses Runtime Application Self-Protection (RASP) technology to detect and block attacks against your Java and PHP applications at runtime — without code changes. Deploy the RASP agent in your application's host or container environment to defend against application vulnerabilities, zero-day vulnerabilities, and in-memory webshell attacks.
What application protection covers:
Detects and blocks 23 attack types for Java applications and 11 for PHP applications
Defends against zero-day vulnerabilities with low false positive and false negative rates
Detects in-memory webshells and blocks both their injection and execution (Java only)
Identifies application weaknesses — such as insecure Fastjson or log4j configurations — before they are exploited (Java only)
Captures full attack chains with original payloads and call stacks for rapid vulnerability remediation
Requires no rule maintenance after deployment
How it works
Application protection hooks into critical functions within your application and monitors how the application interacts with other systems in real time. When suspicious behavior is detected, RASP identifies and blocks the attack based on the full application context — not just network traffic patterns.
Benefits
Secures application internals: Monitors application behavior directly, independent of traffic source, defending against both north-south and east-west threats. Protection starts automatically when the application starts, serving as the last line of defense to ensure applications are secure by default.
Handles complex encoding and encrypted traffic: Because RASP operates inside the application, it inspects fully decrypted request data regardless of how a request is obfuscated at the network layer.
Defends against zero-day vulnerabilities: RASP analyzes data handled by critical functions and ignores attacks that cannot reach execution. This reduces false positives and false negatives. Attackers cannot bypass critical function execution, so RASP can intercept zero-day exploits even when the attack vector is unknown.
Enables rapid attack attribution and remediation: RASP captures full attack chains, including original attack payloads and code call stacks, so security and development teams can quickly locate, reproduce, and fix the vulnerability.
Low operational overhead: Connect your application through the Security Center console. No rule maintenance or updates are required.
Limitations
Application protection supports Java and PHP applications only. It runs on Alibaba Cloud Elastic Compute Service (ECS) instances, third-party cloud servers, and on-premises servers where the Security Center agent is installed.
Supported operating systems:
| Operating system | Supported versions |
|---|---|
| Windows (64-bit) | Windows Server 2025, 2022, 2019, 2016, 2012, 2008; Windows 11, Windows 10 |
| Linux (64-bit) | Alibaba Cloud Linux, AlmaLinux, Anolis OS, CentOS 6/7/8, CentOS Stream, Debian 8 or later, Gentoo, OpenSUSE, RHEL 6/7/8/9, Rocky Linux, SUSE Linux Enterprise Server, Ubuntu 14.04 or later, NeoKylin V7, Kylin V10, TencentOS, Oracle Linux 7/8/9, openEuler 20.03/22.03, EulerOS, Amazon Linux 2/2023 |
Capabilities
Attack detection (Java applications)
The following table lists the attack types that application protection detects and blocks for Java applications, along with remediation guidance.
| Attack type | Description | Remediation |
|---|---|---|
| JNI injection | After gaining code execution privileges, attackers use Java Native Interface (JNI) functions to load malicious dynamic-link libraries, bypassing Java-layer security protections and concealing malicious behavior. | Identify the vulnerable code location and restrict code execution capabilities. |
| SQL injection | Attackers insert SQL commands into page requests or web form query strings to trick the server into executing arbitrary SQL statements. | Use precompiled statements for input parameters. Alternatively, restrict parameter concatenation using whitelists or blacklists. |
| XML external entity (XXE) injection | When an XML parser processes external entities, attackers can exploit this to read arbitrary files, execute commands, or launch internal network attacks. | If your application does not need to load external entities when parsing XML, disable external entity processing in your XML parser configuration. |
| Malicious DNS queries | Attackers use the DNS protocol to bypass internal network restrictions and exfiltrate sensitive information, or to probe internal systems for vulnerabilities such as server-side request forgery (SSRF) or JNDI injection. | Review parameters that servers send to user-controlled addresses and restrict them using a whitelist. |
| Malicious reflective invocation | Attackers attempt to modify RASP runtime data through reflection to disable RASP's self-protection mechanisms. | Identify the vulnerable code location and restrict code execution capabilities. |
| Malicious outbound connections | SSRF enables attackers to forge requests from the server to attack internal systems. | Restrict the target address range of server-initiated requests. Allow access only to trusted internal resources using a whitelist. Disable unnecessary external network access. |
| Malicious file read/write | If file paths or content are not properly validated, attackers can read sensitive system files or upload malware using Java's RandomAccessFile class. | Verify that file reading and uploading work as expected. If anomalies occur, inspect the relevant function code and apply blacklist restrictions. |
| Malicious file upload | If a website does not restrict uploaded file types, attackers can upload malware to gain elevated server privileges. | Restrict allowed file types. Block uploads of executable files such as JSP. |
| Command execution | When servers fail to filter user-supplied commands, attackers can run arbitrary system commands. | Locate where commands are executed. Remove web shells immediately. If the feature is legitimate, restrict allowed commands using a whitelist. |
| Directory traversal | Website misconfigurations may allow unrestricted browsing of website directories, exposing private information that enables further attacks. | Verify that directory traversal operations behave as expected. If anomalies occur, inspect the relevant function code and use a blacklist to restrict dangerous patterns such as ./ and ../. |
| In-memory webshell injection | Attackers inject webshells directly into memory using specialized techniques to evade detection by WAF and host-based defenses. | Identify the vulnerable code location and restrict code execution capabilities. |
| Arbitrary file read | If a website allows file downloads or reads using absolute paths or directory traversal characters without validating file paths, attackers can retrieve sensitive information. | Verify that file reading works as expected. If anomalies occur, inspect the relevant function code and use a blacklist to restrict input parameters such as ./ and ../. |
| Thread injection | After gaining code execution privileges, attackers create new threads to disrupt RASP's runtime context and weaken its protection. | Identify the vulnerable code location and restrict code execution capabilities. |
| Malicious Attach | Attackers use the Java Attach API for dynamic bytecode modification at runtime to inject agent-style in-memory webshells, which are highly evasive. | Identify the vulnerable code location and restrict code execution capabilities. |
| JNDI injection | If attackers control the lookup URL during JNDI lookups, they can force the server to fetch and load malicious classes, enabling arbitrary code execution. | If the vulnerability originates from a third-party component, upgrade to a patched version immediately. If you wrote the JNDI lookup code, restrict the lookup URL and block dangerous protocols. |
| Dangerous protocol usage | If the server accesses user-controlled URLs without restricting the protocol, attackers can read sensitive files using dangerous protocols such as file or netdoc. | Restrict the protocols allowed in URLs. |
| Deserialization attack | Java deserialization reconstructs Java objects from serialized character sequences. If the reconstructed object contains high-risk code, attackers can trigger malicious behavior by manipulating member variables during deserialization. | Upgrade vulnerable components to patched versions immediately. If no patch is available, disable the affected functionality temporarily. |
| Arbitrary file deletion | If a website's file deletion interface does not validate file paths, attackers can delete any file using absolute paths or directory traversal characters. | Verify that file deletion works as expected. If anomalies occur, inspect the relevant function code and use a blacklist to restrict input parameters such as ./ and ../. |
| Expression language injection | Expression libraries support high-privilege operations such as function calls. If attackers control expression content without proper restrictions, they can execute arbitrary code. | Strictly restrict expression input and block most Java function calls. If the issue stems from a third-party component, upgrade to a patched version immediately. |
| Engine injection | Third-party engines — such as Rhino and Nashorn (JavaScript) and Velocity and FreeMarker (template engines) — support high-privilege operations. If attackers control engine input without restrictions, they can execute arbitrary code. | Strictly restrict engine input and block most Java function calls. If the issue stems from a third-party component, upgrade to a patched version immediately. |
| Malicious Beans binding | Some Java frameworks bind runtime Beans to request parameters. If Bean types are not restricted, attackers can modify sensitive Beans to disrupt application behavior or execute arbitrary code. | Restrict the types of Beans that can be bound. Block modifications to sensitive types such as Class and ClassLoader. If the issue stems from a third-party component, upgrade to a patched version immediately. |
| Malicious class loading | Many zero-day exploits and webshells rely on malicious class loading to gain code execution privileges during class initialization. | If malicious class loading is driven by a webshell, remove the webshell immediately. If it stems from a framework, upgrade to a patched version immediately. |
| JSTL arbitrary file inclusion | If user-controllable parameters are directly concatenated into JavaServer Pages Standard Tag Library (JSTL) tags without validation, attackers can craft malicious scripts to read arbitrary files or launch SSRF attacks. | Avoid directly concatenating user-controllable parameters into JSTL tags. If unavoidable, enforce strict whitelist validation on the parameter content. |
Attack detection (PHP applications)
The following table lists the attack types that application protection detects and blocks for PHP applications, along with remediation guidance.
| Attack type | Description | Remediation |
|---|---|---|
| Malicious file inclusion | Attackers include and execute arbitrary files by manipulating input to functions such as include(), require(), include_once(), or require_once(). | Validate and restrict user-supplied file paths. Allow only predefined files from your application directory. |
| Malicious outbound connection | SSRF allows attackers to forge requests from the server to attack internal systems. | Restrict the target address range for server-initiated requests. Use a whitelist to allow access only to trusted internal resources. Disable unnecessary outbound network access. |
| Deserialization | Attackers execute arbitrary functions by manipulating serialized data passed to the unserialize() function. | Avoid directly deserializing untrusted data. Use json_decode() or other secure alternatives. If deserialization is required, strictly validate and filter the data source. |
| Callback function execution | Attackers control parameters of callback functions such as array_map() or array_filter() to execute arbitrary functions and take full control of the system. | Ensure that callback function names passed to array_map(), array_filter(), and similar functions are not controlled by user input. Validate all allowed callbacks using a whitelist. |
| Malicious file read/write | If file read/write functions do not restrict file paths or content, attackers can read sensitive system files or upload malware. | Strictly validate and restrict file paths. Allow access only to predefined directories. Scan file content for malicious code before upload. |
| Arbitrary code execution | Attackers inject malicious code when applications fail to properly validate user input, enabling them to run arbitrary code on the server. | Use strict input validation and output encoding. Avoid using eval() or include() to process user input directly. Keep all libraries and frameworks up to date. |
| Arbitrary file read | Attackers use absolute paths or directory traversal sequences such as ../ to read and download files when file read interfaces lack filtering and path restrictions. | Apply strict input validation and path restrictions to file read interfaces. Allow access only to files verified by a whitelist. Block dangerous input patterns such as ./ and ../ using a blacklist. |
| Arbitrary file deletion | Attackers use absolute paths or directory traversal sequences to delete any file when file delete interfaces lack path restrictions. | Apply strict input validation and path restrictions to file delete interfaces. Allow deletion only of verified files. Block dangerous input patterns such as ./ and ../ using a blacklist. |
| Command execution | Attackers inject operating system commands directly into the backend server by exploiting insufficient input validation. | Strictly validate and filter all user input. Never build OS commands directly from unprocessed input. Use secure APIs instead of system command execution whenever possible. |
| Directory traversal | Poor server configuration may allow attackers to browse website directories freely, leaking private information and enabling further attacks. | Configure proper server permissions and use files such as .htaccess to restrict directory access. Make sure sensitive directories are not publicly browsable. |
| Malicious file upload | If file upload functionality does not restrict file types, attackers can upload malware to gain higher privileges. | Strictly restrict and validate uploaded file types. Allow only safe file extensions. Block executable extensions such as .php. Recheck file content on the server to confirm safety. |
Application vulnerability defense
Application protection defends against application vulnerabilities, zero-day vulnerabilities, and in-memory webshells. During an emergency response, RASP quickly blocks ongoing attacks while you work on a permanent fix, and helps you identify the source and scope of the risk. For more information, see View and handle vulnerabilities.
If you cannot immediately fix an application vulnerability, connect the application process to RASP for protection. To enable RASP protection on applications with detected vulnerabilities:
Log on to the Security Center console.Log on to the Security Center console.
In the left navigation pane, choose Risk Governance > Vulnerabilities. In the upper-left corner, select the region where your assets reside: Chinese Mainland or Outside Chinese Mainland.
On the Application Vulnerability tab, find a vulnerability with the RASP supports real-time protection. tag, then click Enable Protection Now in the Actions column.
In the Application Protection Access panel, select the target application group from the Application Group Name drop-down list, select the relevant asset, and click Confirm. If the required application group does not exist, click Create Application Group from the drop-down list, enter a name, and click OK. By default, the prevention mode is set to Block and the protection policy group is set to Normal Running Group.
After you connect an application to RASP and complete one vulnerability scan, the server's status in the Unhandled Vulnerabilities list on the vulnerability details page changes to Protected.
Application behavior analysis
The application behavior analysis feature monitors connected applications in real time, collects and analyzes behavioral data, and generates reports with visualizations. Use these reports to understand attack and defense details and harden your application security. For more information, see Application behavior analysis.
In-memory webshell defense (Java applications only)
Application protection uses RASP to analyze memory data in real time, detect in-memory webshells, and block both their injection and execution. For more information, see In-memory webshell defense.
Weakness detection (Java applications only)
Application protection scans running Java applications for security weaknesses — misconfigurations and weak credentials that attackers can exploit before a vulnerability is even published.
| Weakness | Risk level | Description | Remediation |
|---|---|---|---|
| Insecure Fastjson configuration | Critical | Fastjson deserialization is enabled. Attackers can exploit this to achieve remote code execution (RCE). | Set Fastjson's safemode to true or autotype to false. |
| Insecure log4j configuration | Critical | Your log4j component has lookup enabled. Attackers can exploit this for JNDI injection, leading to RCE. | Upgrade log4j to the latest version, or delete org/apache/logging/log4j/core/lookup/JndiLookup.class from the JAR file. |
| Insecure startup parameters | Critical | If attackers can access the JDWP debugging port, they can execute arbitrary code. | Close the JDWP port or avoid exposing it on the public network. Monitor long-running applications to make sure JDWP is not enabled. |
| Weak Shiro key | Critical | Your Shiro application uses a weak encryption key. Attackers can crack it and launch deserialization attacks to achieve RCE. | Update the Shiro encryption key immediately. |
| Insecure JMX configuration | Medium | Remote JMX connections are enabled with weak authentication. Attackers may connect remotely and execute commands. | Disable remote JMX connections, or use a strong authentication password. |
| Insecure Rhino configuration | Medium | The Rhino framework includes dangerous properties that attackers can exploit for RCE. | Upgrade Rhino to the latest version. Then use SafeStandardObjects to define the Rhino context and prevent the JavaScript engine from calling Java code. Example: Scriptable scope = ctx.initSafeStandardObjects(); instead of ctx.initStandardObjects(). |
| Insecure Spring configuration | Medium | Spring Actuator has endpoints such as heapDump, env, restart, refresh, trace, jolokia, and h2-console enabled. This may leak sensitive information or enable RCE. | Disable these endpoints unless they are required. |
| Weak login credentials | Medium | Your application uses weak login passwords. Attackers may brute-force them to access your system. | Change the application password to a strong one immediately. |
| Insecure JNDI configuration | Low | Your application uses insecure settings for useCodebaseOnly, rmi-trustURLCodebase, or ldap-trustURLCodebase, creating a JNDI injection risk. | Upgrade the JDK to the latest version. If you cannot upgrade, add the following startup parameters: -Djava.rmi.server.useCodebaseOnly=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=false -Dcom.sun.jndi.ldap.object.trustURLCodebase=false |
| Insecure XML entity configuration | Low risk | XML external entity parsing is enabled, which may expose your application to XXE attacks. | Unless required, disable external entity processing. |
| Weak database password | Low | Your application uses a weak password to connect to the database. Attackers may use it to access your database, leak sensitive data, or achieve RCE. | Change the database connection password to a strong one immediately. |