IDS17-J. Prevent against code injection

Code injection is caused as a result of malicious user input being injected into dynamically constructed code. The javax.script package provides utilities to use various scripting engines from Java code. If misused, an attacker can execute arbitrary code on the target system. This class of vulnerabilities is dangerous because any violations of secure coding practices in dynamically generated code cannot be statically determined.

Noncompliant Code Example

This noncompliant code example uses dynamically obtained user input in a javascript statement, responsible for printing the input. A hostile user may enter specially crafted input parameters in an attempt to inject malicious javascript. The firstName string contains javascript code that can create or overwrite an existing file on the system running the vulnerable Java code.

String firstName = "dummy\'); var bw = new JavaImporter(java.io.BufferedWriter); 
                    var fw = new JavaImporter(java.io.FileWriter); 
                    with(fw) with(bw) { 
                    bwr = new BufferedWriter(new FileWriter(\"c://somepath//somefile.txt\"));
                    bwr.write(\"some text\"); bwr.close(); } // "; // Windows path
	  
evalScript(firstName);

private static void evalScript(String firstName) throws ScriptException {
  ScriptEngineManager manager = new ScriptEngineManager();
  ScriptEngine engine = manager.getEngineByName("javascript");
  engine.eval("print('"+ firstName + "')");	
}

Compliant Solution

The best defense against code injection vulnerabilities is to avoid including executable user input in code. If some dynamic code requires certain user input, the input should be sanitized. For example, a top-level method should ensure that the string firstName contains only valid characters. Refer to the guideline IDS08-J. Sanitize before processing or storing user input for more details.

In addition, a complementary policy is to create a secure sandbox using a security manager (ENV30-J. Create a secure sandbox using a Security Manager). This approach is akin to the one discussed in the first compliant solution of IDS12-J. Prevent XML external entity attacks. The application should not allow the script to execute arbitrary commands such as querying the local file system. The two-argument form of doPrivileged() can also be used to lower privileges when the application must operate with higher privileges but the scripting engine must not. Refer to the guideline SEC00-J. Follow the principle of least privilege for more details on the two-argument form.

// First sanitize firstName

// Single-argument form, used when the application is given the most restrictive permissions
try {
  AccessController.doPrivileged(new PrivilegedExceptionAction() {
    public Object run() throws ScriptException {
      engine.eval("print('"+ firstName + "')");		
      return null;
    }    	
  });
} catch(PrivilegedActionException pae) {    	
  // Handle
}       

Risk Assessment

Failing to prevent against code injection can result in the execution of arbitrary code.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]] Package javax.script
[[OWASP 08]] Code injection in Java

FIO36-J. Do not create multiple buffered wrappers on an InputStream      09. Input Output (FIO)      09. Input Output (FIO)