Potential HTTP Response Splitting

Bug Pattern: HTTP_RESPONSE_SPLITTING

When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks. According to OWASP, the issue has been fixed in virtually all modern Java EE application servers, but it is still better to validate the input. If you are concerned about this risk, you should test on the platform of concern to see if the underlying platform allows for CR or LF characters to be injected into headers. This weakness is reported with lower priority than SQL injection etc., if you are using a vulnerable platform, please check low-priority warnings too.

Code at risk:

  1. String author = request.getParameter(AUTHOR_PARAMETER);
  2. // ...
  3. Cookie cookie = new Cookie("author", author);
  4. response.addCookie(cookie);

References
OWASP: HTTP Response Splitting
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Response Splitting’) CWE-93: Improper Neutralization of CRLF Sequences (‘CRLF Injection’)

Potential CRLF Injection for logs

Bug Pattern: CRLF_INJECTION_LOGS

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).

Code at risk:

  1. String val = request.getParameter("user");
  2. String metadata = request.getParameter("metadata");
  3. [...]
  4. if(authenticated) {
  5.     log.info("User " + val + " (" + metadata + ") was authenticated successfully");
  6. }
  7. else {
  8.     log.info("User " + val + " (" + metadata + ") was not authenticated");
  9. }

A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".

Solution:

You can manually sanitize each parameter.

  1. log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");

You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function.

  1. <pattern>%-5level - %replace(%msg){'[\r\n]', ''}%n</pattern>

Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging has an implementation for Logback and Log4j.

References
CWE-117: Improper Output Neutralization for Logs
CWE-93: Improper Neutralization of CRLF Sequences (‘CRLF Injection’)
CWE-93: Improper Neutralization of CRLF Sequences (‘CRLF Injection’)
OWASP Security Logging