Can random characters in your code get you in trouble? They certainly can! Today, we are going to discuss CRLF injections and improper neutralization of their sequences in Java applications.

Let’s begin!

The concept of CRLF has a long history. It first appeared on typewriters where it was used to signify the end of a line. It has been in use since computers became commonplace.

• CR: It is the MCS character of the carriage return character. The translation character is \r, the ASCII code decimal is 13, and the ASCII code hexadecimal is 0D.
• LF: It is the MCS character of a newline character. The translated character is \n, ASCII code decimal is 10, and ASCII code hexadecimal is 0A.

Source

The carriage return character can move the cursor to the beginning of the current line, and the newline character can move the cursor to the next line vertically.

This operation can be performed by pressing Enter on the keyboard. However, there are different line feed operators on different operating systems:

• Windows:

Use CRLF to indicate line break.

• Linux/Unix:

Use LF to indicate line feed.

• MacOS:

Initially, MacOS used CR to indicate line breaks. But now, like Linux, it seems to also use LF to indicate line break.

CRLF Injection

Let’s try to understand what CRLF injection is. In response to an HTTP request from a web browser, a web server sends a response, which contains both the HTTP headers and the actual content of the website. There is a special combination of characters that separates the HTTP headers from the HTML response (the website content), namely a carriage return followed by a line feed.

When a header ends with a CRLF, a new header is created on the server. So, a web application or a user will know when a new line begins in a file or text block.

An attacker can inject information into HTTP responses by using the CRLF characters that separate HTTP responses. As long as the header and body end in *CRLF>*CRLF>, the browser will understand that the header ends. Consequently, they have the option to store data in the body of the answer, where HTML is stored.

If an attacker enters the ASCII code for carriage return (%0d) and line feed (%0a) in a HTTPS header, they could identify them easily. The result would look like this:

https://xyz.com/index.php?page=home%0d%0a

Effects of CRLF Injection

However, while CRLF injection attacks may not be as precise as most attacks, they can still be dangerous at times. It is possible to mess up a log file by adding an extra line, triggering automatic cybersecurity defenses that notify administrators that a non-issue has appeared. In this case, however, resources might be diverted away from a simultaneous incursion.

However, CRLF attacks are also capable of directly damaging systems. It is possible for an application to display the search results if the query contains an CRLF code rather than hide it. This is usually the case where applications have been designed to accept commands and then search for a specific file. Tese displayed search results can reveal valuable information to attackers.

End-of-line injecting can also be used to create response splitting attacks. The end-of-line codes disassemble a valid response into pieces. In such cases, hackers can gain control of the header after the CRLF code, allowing them to inject more code. CRLF attacks can also be used by attackers to insert their own code into the following line, which will likely lead to another attack on those lines.

Improper Neutralization of CRLF Sequences in Java

Java applications improperly neutralize CRLF sequences when they receive data from an upstream component and fail to neutralize or incorrectly neutralize CR and LF characters before adding them to HTTP headers. Sometimes, the improper neutralization error can be a false positive.

For example:

Here is a Java code that sets the name of the author of a blog post on a website in the cookie header of the HTTP response based on the results of an HTTP request.

String author = request.getParameter(AUTHOR_PARAM);

Cookie cookie = new Cookie(“author”, author);

cookie.setMaxAge(cookieExpiration);

response.addCookie(cookie);

The HTTP response including this cookie might look like the following if a string containing standard alpha-numeric characters such as “Adam Berg” is included in the request:

HTTP/1.1 200 OK

…

Set-Cookie: author=Adam Berg

…

AUTHOR_PARAM will only be maintained if it does not contain any CR or LF characters. This is because the cookie value has a user input value that has not been validated. The attacker may submit malicious characters like:

James\r\nHTTP/1.1 200 OK\r\n

If the HTTP response needs to be split into two, it would look like this:

HTTP/1.1 200 OK

…

Set-Cookie: author=James HTTP/1.1 200 OK

…

It is obvious that the attacker has complete control over the second response. It can include any header and body content they choose. A variety of attacks are possible due to the attackers’ ability to construct arbitrary HTTP responses, including defacement, cross-user injection, cache poisoning, and cross-site scripting.

How to Fix CRLF Injection or Improper Neutralization Error

Some tools may report improper neutralization as a false positive in which case you don’t have to make any changes. However, ESAPI httputilities present in the esapi jar are the simplest method to resolve the issue of improper neutralization. This can be done by using:

ESAPI.httpUtilities().setHeader(response,param,value);

ESAPI.httpUtilities().addCookies(response, param,value);

However, if you want to find a more efficient solution that simplifies the process, you can use WhiteSource Cure, a free auto-remediation application that you can integrate into your development environment. It helps you solve this and many other security issues. This can vastly increase the productivity of your team as you just have to focus on releasing software.

To solve the above problem using Cure, first, you have to copy the link to your GitHub repo. In this example, I will use the WebGoat Legacy repo, which is a deliberately insecure JavaEE application that can be used for testing.

The second step involves simply pasting the link of the repo you want to test on WhiteSource Cure

Next, WS Cure shows you a list of all vulnerabilities in the repo. If you want to check any particular vulnerability you can do that by simply clicking on it. You can see the fix suggested by WS Cure by clicking on the remediation tab:

Conclusion

CRLF Injection attacks are not very frequently discussed because their scope of damage doesn’t seem serious to many. However, as we have discussed above, this is a very incorrect idea.

Make sure you have a look at the various solutions mentioned here and see which works for you when you’re trying to neutralize CRLF sequences. Do let me know if you have any feedback.

Good luck!