How to remediate – Expression Language Injection

1. Introduction

Expression Language Injection (ELI) is a vulnerability that occurs when an application evaluates expressions derived directly from untrusted user inputs. This allows attackers to inject malicious code, potentially gaining access to sensitive information or executing commands on the server. Systems using Java Server Pages Standard Tag Library (JSTL), Apache Jakarta, Struts, WebWork, MVFLEX Expression Language (MVEL) and Spring Expression Language (SPEL) are commonly affected. A successful exploit could compromise confidentiality, integrity, and availability of data.

2. Technical Explanation

• Root cause: Unsafe evaluation of untrusted user-controlled input within an expression interpreter.
• Exploit mechanism: An attacker injects malicious code into a user input field that gets processed by the expression language engine, leading to remote code execution or data disclosure. For example, injecting `${runtime.getRuntime().exec(“command”)}` into a vulnerable application using SPEL could execute arbitrary commands on the server.
• Scope: Applications utilizing JSTL, Apache Jakarta, Struts, WebWork, MVFLEX Expression Language (MVEL), and Spring Expression Language (SPEL) are affected.

3. Detection and Assessment

To confirm vulnerability, first check application versions using the methods below. Then perform a thorough scan of source code for insecure expression evaluations.

• Quick checks: Check the version of Java runtime environment (JRE) or Java Development Kit (JDK) used by the application.
• Scanning: Static analysis tools can identify potentially vulnerable EL expressions in source code. Example signatures include searches for user input directly within EL expressions.
• Logs and evidence: Examine application logs for errors related to expression parsing or evaluation, particularly if they involve user-supplied data.

java -version

4. Solution / Remediation Steps

The following steps provide a secure fix for the issue.

4.1 Preparation

• Stop the application service to prevent further exploitation during remediation. A rollback plan involves restoring from the previous backup.
• Changes should be approved by security team.

4.2 Implementation

1. Step 1: Avoid evaluating expressions derived directly from untrusted user inputs.
2. Step 2: If expression evaluation is necessary, strictly validate user-supplied data using an allowlist approach.
3. Step 3: Filter special characters that could be used in malicious EL payloads.

4.3 Config or Code Example

Before

String expression = request.getParameter("userInput");
// Evaluate the expression directly
Object result = evaluator.evaluate(expression);

After

String userInput = request.getParameter("userInput");
// Validate input against an allowlist of safe characters/patterns
if (isValidInput(userInput)) {
  String expression = sanitizeInput(userInput);
  Object result = evaluator.evaluate(expression);
} else {
  // Handle invalid input appropriately
}

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Least privilege: Run the application with the minimum necessary privileges to reduce the impact of a successful exploit.

4.5 Automation (Optional)

Automated scanning tools can help identify vulnerable EL expressions in source code.

# Example using a static analysis tool
./static_analyzer --scan /path/to/application --rules el_injection

5. Verification / Validation

Confirm the fix by re-running the earlier detection methods and performing a negative test.

• Re-test: Re-run the initial vulnerability scan to confirm that no vulnerable EL expressions are detected.
• Monitoring: Monitor application logs for any errors related to expression parsing or evaluation.

java -version # Verify JRE version remains unchanged

6. Preventive Measures and Monitoring

Implement preventive measures to avoid similar vulnerabilities in the future.

• Baselines: Update security baselines to include secure coding practices for expression languages.
• Pipelines: Integrate static analysis tools into CI/CD pipelines to automatically detect vulnerable EL expressions during development.
• Asset and patch process: Maintain a regular patch cycle for all application dependencies, including Java runtime environments and related libraries.

7. Risks, Side Effects, and Roll Back

Applying the fix may introduce compatibility issues with existing code that relies on unsafe expression evaluation.

• Risk or side effect 1: Strict input validation might break legitimate use cases if not implemented carefully.
• Risk or side effect 2: Filtering special characters could inadvertently block valid inputs.

8. References and Resources

• Vendor advisory or bulletin: https://mindedsecurity.com/wp-content/uploads/2020/10/ExpressionLanguageInjection.pdf
• NVD or CVE entry: Not applicable, as this is a general vulnerability class.
• Product or platform documentation relevant to the fix: https://owasp.org/www-community/vulnerabilities/Expression_Language_Injection