Injection Prevention Cheat Sheet in Java



{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- Last revision (mm/dd/yy): // = Introduction =
 * valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

This document has for objective to provide some tips to handle Injection into Java application code.

Sample codes used in tips are located here.

= What is Injection ? =

Injection in OWASP Top 10 is defined as following:

Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.

= General advices to prevent Injection =

The following point can be applied, in a general way, to prevent Injection issue:


 * 1)  Apply Input Validation (using whitelist approach) combined with Output Sanitizing+Escaping on user input/output.
 * 2)  If you need to interact with system, try to use API features provided by your technology stack (Java / .Net / PHP...) instead of building command.

Additional advices are provided on this cheatsheet.

= Specific Injection types =

Examples in this section will be provided in Java technology (see Maven project associated) but advices are applicable to others technologies like .Net / PHP / Ruby / Python...

Symptom
Injection of this type occur when the application use untrusted user input to build a SQL query using a String and execute it.

How to prevent
Use Query Parameterization in order to prevent injection.

Symptom
Injection of this type occur when the application use untrusted user input to build a JPA query using a String and execute it. It's quite similar to SQL injection but here the altered language is not SQL but JPA QL.

How to prevent
Use Java Persistence Query Language Query Parameterization in order to prevent injection.

Symptom
Injection of this type occur when the application use untrusted user input to build a Operating System command using a String and execute it.

How to prevent
Use technology stack API in order to prevent injection.

Symptom
Injection of this type occur when the application load the received XML stream using a XML parser instance in which the resolution of External Entity is not disabled.

How to prevent
Disable to resolution of the External Entity in the parser instance to prevent injection.

Symptom
Injection of this type occur when the application use untrusted user input to build a XPath query using a String and execute it.

How to prevent
Use XPath Variable Resolver in order to prevent injection.

Example
Variable Resolver implementation.

Code using it to perform XPath query.

Symptom
Injection of this type occur when the application use untrusted user input to build a HTTP response and sent it to browser.

How to prevent
Either apply strict input validation (whitelist approach) or use output sanitizing+escaping if input validation is not possible (combine both every time is possible).

LDAP
A dedicated cheatsheet has been created.

Symptom
Injection of this type occur when the application use untrusted user input to build a NoSQL API call expression.

How to prevent
As there many NoSQL database system and each one use a API for call, it's important to ensure that user input received and used to build the API call expression do not contains any character that have a special meaning in the target API syntax. This in order to avoid that it will be used to escape the initial call expression in order to create another one based on crafted user input. It's also important to not use string concatenation to build API call expression but use the API to create the expression.

Log Injection
This section is under work, so, is not yet ready for production usage!

Symptom
Log Injection occurs when an application includes untrusted data in an application log message (e.g., an attacker can cause an additional log entry that looks like it came from a completely different user, if they can inject CRLF characters in the untrusted data).

More information about this attack is available on the OWASP Log Injection page.

How to prevent
To prevent an attacker from writing malicious content into the application log, apply defenses such as:


 * Filter the user input used to prevent injection of Carriage Return (CR) or Line Feed (LF) characters.
 * Limit the size of the user input value used to create the log message.
 * Make sure all XSS defenses are applied when viewing log files in a web browser.

Example using Log4j2
Configuration of a logging policy to roll on 10 files of 5MB each, and encode/limit the log message using the |Log4j2 Pattern encode{}{CRLF}, introduced in Log4j2 v2.10.0, and the -500m message size limit.:

Usage of the logger at code level:

Example using Logback along the OWASP Security Logging project
Configuration of a logging policy to roll on 10 files of 5MB each, and encode/limit the log message using the CRLFConverter, provided by the OWASP Security Logging project, and the -500msg message size limit:

Usage of the logger at code level: