What Is Expression Language Injection?

Code injection is a critical vulnerability that allows a third party to execute code on the server-side software. Expression language injection is a type of remote code execution that discloses sensitive data from the server. The remote code executes and displays variables, passwords, functions, or code. At worst, it can give an attacker remote control of the server.

What Is Expression Language Injection?

Expression language injection is a vulnerability affecting JavaServer Pages (JSP), Active Server Pages (ASP), and other expression languages hosted on a web server. These languages are interpreted languages, so any code sent to the server is compiled during runtime of the application, as opposed to standard compiled languages with binary executable files. In an interpreted language, the code compiles on the server when a user makes a request for a page.

When an expression language (EL) application is vulnerable to expression language injection, an attacker sends crafted code to the application as input, either in the query string or in a form object. The code is compiled at runtime, and the code can then display variables, passwords, and other sensitive information. EL vulnerabilities are common in outdated versions of interpreted languages, so legacy applications should be penetration tested before deploying them to production. After a critical event, organizations need disaster recovery plans to remediate data disclosure and exploits.

How Expression Language Injection Works

Any application running an interpreted language should scrub code and special characters from input. Without scrubbing input, the application will accept code and execute it on the server. Most EL injection vulnerabilities involve JSP, so we’ll use JSP code in the following example. The snippet below is an example of a single line of code vulnerable to EL injection:

<spring:message code="${param['message']}" text=""/>

In this example, the code attribute takes a parameter containing a string. If an attacker injects code into the parameter, it will be compiled and executed on the server. Users do not see this code in their local web page, so attackers use common scripts to find EL injection vulnerabilities.

Common Vulnerabilities Leading to Expression Language Injection

Similar to any injection vulnerability, the EL injection vulnerability stems from no validation of input on the server application. Using the same example as above, the message string could be an innocent string of characters, but it could also be code. Instead of sending an innocent string, suppose the user sent the following:

${"aaaa".toString().concat(T(java.lang.Runtime).getRuntime().exec('ls -l'))}

The above input attempts to run the system command “ls -l” on the server. This command lists the files and directories in the current directory. With a list of files, an attacker could then attempt to send another command to open and display a file’s content to their window. A file could contain sensitive data such as passwords. From there, the attacker could potentially access the server and perform additional malicious actions.

Detecting Expression Language Injection

Penetration testing—both white box and black box—will detect EL injection vulnerabilities. White box testing is a method where security professionals review code for vulnerabilities. Businesses supply the code to security reviewers, and reviewers identify all code vulnerabilities in a report. It’s a common proactive approach to data protection.

Black box penetration testing uses the same form of scans and vulnerability detection as an attacker. Security professionals attack the application without knowing the code, so any validation or defenses can be tested. Gray box testing is a mix of black box and white box testing and is often a chosen method for penetration testing web applications.

Preventing Expression Language Injection

The best way to detect EL injection attacks is to validate code and remove input with specific characters. For example, input for a name field should not have “<” or “>” characters in it. Developers should use libraries built to detect these characters and remove them or drop the input and display an error to the user.

Other characters can also be malicious. In a JSP page, code snippets start with the “<%” characters and end with the “%>” characters. These characters together should be removed from input. Attackers will perform numerous combinations of malicious code to bypass detection, so the best way to detect it is to use a library built for input validation. SIEM applications can also detect exploits and provide analytics if your application is a target.

Conclusion

EL injection vulnerabilities should be treated as critical security issues. Always have your interpreted language applications tested for injection vulnerabilities and any others that could disclose sensitive data. Developers should use validation tools to detect and stop EL injection, and legacy applications using JSP and ASP should be closely monitored for attacks.

Everpure has the security infrastructure and threat monitoring in place to protect your applications from security attacks.