Year Of Security for Java – Week 12 – Log Forging Prevention

No Gravatar

What is it and why should I care?
Log forging is an issue that can occur if you allow un-trusted data to be written to a log storage mechanism. The intent of the attacker using log forging is to cover his tracks in the logs or at least make understanding what he was doing more difficult. Unfortunately, like most log-related issues, it’s generally not a concern until something happens and you actually need the logs.

A simple example of log forging might look like this: (first the code)

String someVar = getRequestParameter("xyz");
log("Data is: " + someVar);

And now for what a normal request and the associated log entry might look like:

?xyz=my name is Bob

[2012-03-15 02:04:31] [bob] Data is: my name is Bob

And finally what a forged request and the associated log entry might look like:

?xyz=my name is Bob\r\n[2012-03-15 02:04:39] [mary] Mary created new user\r\n[2012-03-15 02:04:46] [josh] Josh logged out\r\n[2012-03-15 02:04:55] [susan] Susan performed an important transaction

[2012-03-15 02:04:31] [bob] Data is: my name is Bob
[2012-03-15 02:04:39] [mary] Mary created new user
[2012-03-15 02:04:46] [josh] Josh logged out
[2012-03-15 02:04:55] [susan] Susan performed an important transaction

The idea here is that the attacker has surmised what a standard log entry might look like and then using simple newline characters created what appear to be new legitimate log entries.

Note: If you are using a database for logging, you likely won’t have as much of an issue since each entry is going to be in a single row. However, it could still affect you if your log viewer doesn’t distinguish between rows. However, you still need to be aware of SQL injection here, which is actually a much more serious issue.

What should I do about it?
Fortunately, log forging has a relatively simple fix.

The general approach is to validate input (you should already be doing this) and encode output (you also should be doing this). Validating input alone is not generally going to stop this attack, since there are valid cases to allow input with newlines. Encoding output in addition to validating the input, however, should solve your problem. There are various options for encoding depending on your needs. A simple fix might be to strip out any user-supplied newlines or replace them with some benign character or character sequence. Another alternative might be to HTML encode the data before storing it. This allows you to decode the data later if you need to get back to the original data, as well as have it set up nicely for a web-based log viewing experience if that’s desirable.

Log forging is a simple issue to understand and solve – it just takes some planning ahead to deal with properly. You’ll be glad you did though when you get that 3am call to look through the logs and figure out what’s happening!

I’ve actually already written a longer, more detailed article about log forging prevention here, but this shorter version was meant to show the essentials and fits in with the year of security for Java content.

References
———–
http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/

Be Sociable, Share!

Technorati Tags: , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *