Potential code injection when using Script Engine

Bug Pattern: SCRIPT_ENGINE_INJECTION

Dymanic code is being evaluate. A careful analysis of the code construction should be made. Malicious code execution could lead to data leakage or operating system compromised.

If the evaluation of user code is intended, a proper sandboxing should be applied (see references).

Code at risk:

  1. public void runCustomTrigger(String script) {
  2.     ScriptEngineManager factory = new ScriptEngineManager();
  3.     ScriptEngine engine = factory.getEngineByName("JavaScript");
  5.     engine.eval(script); //Bad things can happen here.
  6. }

Solution:

Safe evaluation of Javascript code using “Cloudbees Rhino Sandbox” library.

  1. public void runCustomTrigger(String script) {
  2.     SandboxContextFactory contextFactory = new SandboxContextFactory();
  3.     Context context = contextFactory.makeContext();
  4.     contextFactory.enterContext(context);
  5.     try {
  6.         ScriptableObject prototype = context.initStandardObjects();
  7.         prototype.setParentScope(null);
  8.         Scriptable scope = context.newObject(prototype);
  9.         scope.setPrototype(prototype);
  11.         context.evaluateString(scope,script, null, -1, null);
  12.     } finally {
  13.         context.exit();
  14.     }
  15. }

References
Cloudbees Rhino Sandbox: Utility to create sandbox with Rhino (block access to all classes)
CodeUtopia.net: Sandboxing Rhino in Java
Remote Code Execution .. by design: Example of malicious payload. The samples given could be used to test sandboxing rules.
CWE-94: Improper Control of Generation of Code (‘Code Injection’)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’)

Potential code injection when using Spring Expression

Bug Pattern: SPEL_INJECTION

A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.

Code at risk:

  1. public void parseExpressionInterface(Person personObj,String property) {
  3.         ExpressionParser parser = new SpelExpressionParser();
  5.         //Unsafe if the input is control by the user..
  6.         Expression exp = parser.parseExpression(property+" == 'Albert'");
  8.         StandardEvaluationContext testContext = new StandardEvaluationContext(personObj);
  9.         boolean result = exp.getValue(testContext, Boolean.class);
  10. [...]

References
CWE-94: Improper Control of Generation of Code (‘Code Injection’)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’)
Spring Expression Language (SpEL) - Official Documentation
Minded Security: Expression Language Injection
Remote Code Execution .. by design: Example of malicious payload. The samples given could be used to test sandboxing rules.
Spring Data-Commons: (CVE-2018-1273)
Spring OAuth2: CVE-2018-1260

Potential code injection when using Expression Language (EL)

Bug Pattern: EL_INJECTION

A expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.

Code at risk:

  1. public void evaluateExpression(String expression) {
  2.     FacesContext context = FacesContext.getCurrentInstance();
  3.     ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory();
  4.     ELContext elContext = context.getELContext();
  5.     ValueExpression vex = expressionFactory.createValueExpression(elContext, expression, String.class);
  6.     return (String) vex.getValue(elContext);
  7. }

References
Minded Security: Abusing EL for executing OS commands
The Java EE 6 Tutorial: Expression Language
CWE-94: Improper Control of Generation of Code (‘Code Injection’)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’)
Minded Security: Expression Language Injection
Dan Amodio’s blog: Remote Code with Expression Language Injection
Remote Code Execution .. by design: Example of malicious payload. The samples given could be used to test sandboxing rules.

Potential code injection in Seam logging call

Bug Pattern: SEAM_LOG_INJECTION

Seam Logging API support an expression language to introduce bean property to log messages. The expression language can also be the source to unwanted code execution.

In this context, an expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.

Code at risk:

  1. public void logUser(User user) {
  2.     log.info("Current logged in user : " + user.getUsername());
  3.     //...
  4. }

Solution:

  1. public void logUser(User user) {
  2.     log.info("Current logged in user : #0", user.getUsername());
  3.     //...
  4. }

References
JBSEAM-5130: Issue documenting the risk
JBoss Seam: Logging (Official documentation)
The Java EE 6 Tutorial: Expression Language
CWE-94: Improper Control of Generation of Code (‘Code Injection’)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’)

Potential code injection when using OGNL expression

Bug Pattern: OGNL_INJECTION

A expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.

Code at risk:

  1. public void getUserProperty(String property) {
  2.   [...]
  3.   //The first argument is the dynamic expression.
  4.   return ognlUtil.getValue("user."+property, ctx, root, String.class);
  5. }

Solution:

In general, method evaluating OGNL expression should not received user input. It is intented to be used in static configurations and JSP.

References
HP Enterprise: Struts 2 OGNL Expression Injections by Alvaro Muñoz
Gotham Digital Science: An Analysis Of CVE-2017-5638
Apache Struts2: Vulnerability S2-016
Apache Struts 2 Documentation: OGNL