Hi Justin

Is that true with the latest version of Veracode?? cause at least half year ago i was stuck with ESAPI as the only way to avoid the CWE-117 report. I tried simply replacing \r and \n through a utility method or inline, nothing worked for me. Is like Veracode just looks if you use ESAPI, if you don't, its a flaw. these days, even some newer logging mechanism (log4j2) can be configured to avoid log forging

We set up log4j2 (v2.7) with %encode as OWASP recommends (https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet_in_Java#Log_Injection). It does HTML encoding and CRLF replacement. Ran a scan against our jar and CWE-117 still comes up. Is it correct that we have to mitigate this even though per Justin above this is an expected and proper remediation?

Thanks.

Thank you for your patience. The Veracode system is designed to look for a few different solutions for remediating CRLF Injection in Logs(CWE117).

ESAPI Library is a legacy option used by older applications, and it is recognized by the Veracode system.

There's a list of supported cleansers that have been reviewed by our Research team that can be used inline when logging data external to the application. The list can be found in our help center at the following link.

Supported Cleansers

https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/IiF_rOE79ANbwnZwreSPGA

@EVelázquez833798 (Community Member)​  You can create your own helper function to strip out the offending characters, but it will have to be reviewed and approved through the mitigation workflow by your security team. This is true for any custom written cleansing functions, because it requires security review for completeness/correctness.

@JMaloney925304 (Community Member)​ The usage of Log4j2 can be a possible remediation, but it will also have to be reviewed and approved through the mitigation workflow by your security team and server administration team. This remediation approach relies on runtime classpath loading the log4j configuration file as such this is not something which can be confirmed via binary analysis.

@Qtran106484 (Community Member)​ The OWASP Security Logging Library is a potential remediation approach, where you need to use the utility function. The alternate approach with this library is to use it with Logback Framework. Either way the use of this library would require you to document a mitigation proposal in the Veracode Platform for approval by your security team.

Primarily this library is used to add some consistency for logging security events, and some masking for possibly sensitive details.

CRLF Utility Method replaceCRLFWithUnderscore()

https://github.com/javabeanz/owasp-security-logging/blob/master/owasp-security-logging-common/src/main/java/org/owasp/security/logging/Utils.java

Logback and OWASP Security Logging Library

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.md#example-using-logback-with-the-owasp-security-logging-library

Hi,

we have similar issue and we are using logback LogstashEncoder which converts every log message into JSON which is then passed into logstash. Currently veracode is reporting issue CWE 117, but I think that this issue is mitigated by library(logback) itself. Is there some way how to configure veracode so it ignores globally on whole project this issue? Because currently every time we add new logging statement we have to go to veracode and manually mitigate this issue with comment.

Thanks.

Hi @JJečmínek184882 (Community Member)​ ,

JSON does not use CR (\r) or LF (\n) as a separator so this component of your architecture should not be vulnerable to injection. However if these statements are later printed in a file that does rely on these characters as as separators your application may still be vulnerable.

If you have verified that your application does not use line delimited files anywhere you can choose to mitigate these flaws: https://docs.veracode.com/r/c_mitigation_performance_review

You can have these mitigations automatically proposed for you (and optionally automatically accepted) if you are using a Custom Cleanser Annotation: https://docs.veracode.com/r/c_frameworks.

Please note that your security team must enable this in the Veracode Platform. Please contact them before using this feature.

Alternatively, you can contact your security and investigate the option of removing this flaw category from your policy compliance

Please let me know if you have any remaining questions or concerns.

Thank you,

Boy Baukema