Spring Boot: CRLF - Securely log payload in REST API

Question

I have a Spring Boot app which exposes a REST API. I need to log the payload to be able to find errors in the JSON in the API calls. I have ran a code analysis tools that reports the following security risk when I log the payload. https://find-sec-bugs.github.io/bugs.htm#CRLF_INJECTION_LOGS

How can I protect against code injection? I guess removing new lines only protect against fake log entries and will not protect against code injection?

REST API:

@PostMapping("/my/api")
public ResponseEntity<String> handleApi(@RequestBody Body body) {

Payload logging:

@Slf4j
public class CustomRequestLoggingFilter extends AbstractRequestLoggingFilter {
private static final int MAX_PAYLOAD_LENGTH = 64000;

public CustomRequestLoggingFilter() {
    this.setIncludeQueryString(true);
    this.setIncludePayload(true);
    this.setMaxPayloadLength(MAX_PAYLOAD_LENGTH);
}

@Override
public void afterRequest(HttpServletRequest request, String message) {
    if (request.getRequestURI().equals("/my/api")) {
        log.info(message); //This is the security risk
    }
}

Answer 1

You can try to use OWASP Json Sanitizer library (https://owasp.org/www-project-json-sanitizer/migrated_content) to clean and sanitize Json input prior logging it. If you are not concerned about adding additional 3rd party dependency to your project.

NOTE: Last release of this library was in Jan 11, 2021

Example:

@Override
public void afterRequest(HttpServletRequest request, String message) {
    if (request.getRequestURI().equals("/my/api")) {
        String sanitizedJson = JsonSanitizer.sanitize(message);
        log.info(sanitizedJson );
    }
} 

Answer 2

The linked report is suggesting a possible solution of replacing newlines to remove the risk:

 log.info(message.replaceAll("[\r\n]",""));

You can manually sanitize each parameter.

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

Or using other solutions which change your logging configuration:

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.

<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.

Answer 3

The vulnerability you are mentioning have nothing to do with code injection, only with the possibility of manipulating your logs.

Remediation for that, if you are producing plain text logs, is to sanitize that message (best with the OWASP library that Dmitriy suggested), but if you are managing your logs with some tool (e.g. ELK), probably you should produce logs in JSON format and that would automatically mitigate this issue for you.

Back to the code injection, considering you have set some max payload length, I don't think you can have any code injection in that log statement.