Enterprise Library Logging Injection Avoidance

Topics: Logging Application Block
Oct 2, 2014 at 1:07 PM
Hello,

A security scan on servers came with the conclusion that

"Logging in Microsoft Enterprise library does not prevent altering of data by unauthorized users"

Was wondering what the solution is to avoid this security hole. One suggestion was to use a wrapper around Enterprise Library. But what feature should we look at handling in this wrapper that would prevent logging injection?

Thanks,
Oct 3, 2014 at 7:41 AM
I'm not sure what that sentence means? Is it talking about data that is already written (e.g. to disk)? Or in memory changes? Or configuration changes? Or is the issue that there is no authentication for the Logger.Write calls?

Can you provide a specific concrete example of what the issue is?

Thanks.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Oct 3, 2014 at 12:23 PM
Randy,

Following might provide some more explanation:
Log injection problems are a subset of injection problem, in which invalid entries taken from user input are inserted in logs or audit trails, allowing an attacker to mislead administrators or cover traces of attack. Log injection can also sometimes be used to attack log monitoring systems indirectly by injecting data that monitoring systems will misinterpret.
Oct 3, 2014 at 6:40 PM
There are a few options In order to mitigate the risks. One option is not to log any user supplied data. That is usually not realistic, however. Another common approach is to sanitize (validate or encode) all user input so that no invalid characters are allowed into your system.

Since similar risks apply to all user input data, it might be a good approach to standardize this cross cutting concern for all user input. If logging is your sole focus then you could create a facade over the logging API that ensures the data is not invalid.

I'm not sure what you are using logging and what the requirements are but you may want to consider other scenarios. e.g. if you are using logging to audit incoming requests how can you prove that your audit information is valid and accurately represents what request was received and what response was returned (non-repudiation). This could be an issue in health care scenarios, for example.


~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to