I got the veracode report for my javaEE app. It had a flaw at any logging (using log4j), so I add the StringEscapeUtils.escapeJava(log)
to all of them, but veracode keeps reporting them as security flaws.
Is this a right solution? What else can I do?
This is the report info: Title: Improper Output Neutralization for Logs
Description: A function call could result in a log forging attack. Writing unsanitized user-supplied data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible.
Recommendations: Avoid directly embedding user input in log files when possible. Sanitize user-supplied data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Only write custom blacklisting code when absolutely necessary. Always validate user-supplied input to ensure that it conforms to the expected format, using centralized data validation routines when possible.
They recommend to use ESAPI, but it is a very big project so I need the simplest solution, tht's why I tried with String.escape 'StringEscapeUtils.escapeJava(log)'
Thx in advanced!
I've run into the same issue and I'm generally ignoring this flaw for a simple reason: A logger just gives me a log event. It shouldn't care about formatting (exposing sensitive data is another issue).
The solution here is to add proper filtering/post-processing in the appender which writes the log event to the log file. At this step, you can remove special characters (
\0
,\r
- carriage return,\b
- backspace,\x1b
- escape and\x7f
- delete) and replace\n
with\n...
to make it impossible to inject fake log lines into the log.When you do this, you can safely ignore all these flaws.
Also, if a sysadmin uses the wrong tools to look at log files (anything which executes escape sequences,
\r
and backspace), he should be fired.I head up the Veracode Application Security Consulting group, and can answer your question in detail. The best venue for the conversation is through Support@veracode.com, since the discussion may involve specific details about your findings that we probably want to avoid making public.
The short answer is the StringEscapeUtils.escapeJava() is effective at eliminating typical CRLF risk, but it is not one of the mechanisms our system automatically recognizes as there are situations in which it may be insufficient.
The Veracode system has a mechanism for marking these findings appropriately so they do not cause confusion.
Please contact Veracode Support (support@veracode.com), and we'll be able to talk in detail.
Best regards, Jim.
There are two issues conflated in this report.
Firstly, there is log injection - using a newline character to spill over into a separate log line.
StringEscapeUtils.escapeJava
produces output that has line delimiters and non-ASCII characters escaped, which in principle ensure this problem is fixed. Veracode doesn't know that, though - as an automated scanner it doesn't know enough about what that method is doing to be able to say for sure, so it has to report there might still be a vulnerability there. Naturally Veracode can't know about every escaping function in third-party library code.Log injection can also happen when you are using your own separators inside a log line, for example
Bad thing happened with parameters {0} and {1}
. In this case if an attacker had the string" and "
in one of the parameters you wouldn't be able to recreate exactly which data was in which parameter. The answer here is to surround the parameters with delimiters that don't appear in the output of the escaping function - for example put double quotes around each value and useescapeJava
to escape any double quote character in the value.The second attack happens outside your application, when some tool is being used to view the logs. If that tool has an injection vulnerability, then metacharacters in the log data can become active. The classic example is viewing logs in a web interface that copies them directly into the page without escaping, resulting in HTML injection and consequently cross-site-scripting in the log viewing application.
If you can be sure that you're only viewing logs in tools that don't suffer from stupid bugs like this, you don't need to worry about it.
Otherwise, try to escape any metacharacters from languages you think might be affected. Typically
<
and&
for HTML. If you don't want to be HTML-escaping all your non-HTML log data, another way you could do it would be to replace those characters with escaped equivalents like\u003E
in the output ofescapeJava
.Again, Veracode won't be able to work out automatically that what you're doing is necessarily safe there so you'll have to mark those reports as ignored/dealt-with once you're happy with it.
Use StringEscapeUtils.escapeHtml(log) to avoid the HTML injections and might solve your problem.
As I could observe (and understand from messages from Veracode) following should be done:
This can achieved by using enodeForHtml() encoding method from ESAPI library. However the library requires some extra configuration (ESAPI.properties) which is redundant if you just want to escape logged values. To overcome this I extracted (and slightly modified) the escaping code. Here is the code:
Now having that function you can log your entries in following way: