hunting-expression-language-injection

Hunting expression-language injection: when a string is evaluated as a program

Expression languages exist to let configuration, templates, and rules evaluate small snippets at runtime, Spring Expression Language, OGNL, MVEL, JEXL, and the Jakarta and JSP EL contexts among them. Most expose far more than arithmetic: type resolution, method invocation, and a handle to the runtime. When untrusted input is concatenated into, or supplied as, an expression that one of these evaluators compiles, the attacker's text is executed with the evaluator's full power, which typically reaches process execution or reflection. This class caused some of the largest breaches on record. You find it by locating every runtime expression evaluation and asking whether untrusted input shapes the expression rather than only supplying a bound variable.

When to use

• The application evaluates expressions at runtime through an EL, OGNL, MVEL, JEXL, or a rules engine.
• Untrusted input is concatenated into an expression string or supplied as an expression to evaluate.
• A framework feature (data binding, templating, routing, error pages) evaluates attacker-reachable EL.

Scope check

Test expression evaluation only against applications you own or are authorized to assess, on non-production infrastructure. A confirming expression runs on the target and typically reaches code execution, so treat every proof as a live intrusion inside the authorized scope. If you can't name the authorization, stop.

The loop

1. Establish the expression evaluators first. Inventory every place a string is evaluated as an expression: explicit calls to an expression parser, template engines backed by an EL, framework features that evaluate EL (data binding, view resolution, error templates, routing rules), and rules engines. This is the false-positive killer: an evaluator fed only fixed developer strings with untrusted data passed as bound variables is not injectable. Name the evaluators first.