github / github/codeql

False positive - LogInjection (CWE 117) is not mitigated via Log4j2 %{encodeCRLF) pattern

Open
#15,574 11 comments 0 reactions 0 assignees View on GitHub
false-positive Java
Dominant language
CodeQL
Stars
10.1k
Forks
2.1k
Avg merge
2d 15h
Merged PRs (30d)
141

Description

Hello,
I have a case where I sanitize user inputs using log4j2 Pattern rule to escape '\n' and '\r' using the encode pattern %encode as follows where the user provided messages to log4j2.log() methods are encoded seamlessly:

Log4j2.xml:

```
PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -%encode{%msg}{CRLF}%n"
```

Code:

```
log("UserId: {}", userId);
...
```
in order to mitigate a LogInjection high vulnebarility (CWE-117) issue reported by CodeQL in Java. The problem is that CodeQL is not happy as it still reports the same set of LogInjection issues after the sanitization.

However, if I sanitize the user provided inputs in the log() messages, using the following method, CodeQL is happy.

```
private String escapeCRLF(String msg) {
return (msg == null ? null : msg.replace("\n", "\\n" ).replace("\r", "\\r" ));
}
...
log("UserId: {}", escapeCRLF(userId));
...
```

So, apparently, CodeQL has a rule to recognize the 2nd mitigation method but somehow it misses the sanitization provided via log4j2 encoding CRLF rule, which has the exact same functionality as the above escapeCRLF method. I like the 1st solution which is uniform throughout the code base, requiring no code change. So, I am wondering if you would know how to make CodeQL happy if I deploy the Log4j2 solution.

Thanks in advance!

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.