Implemented newline encoding to defend against log injection.

[bodine]

Hi Jean,

This pull request implements newline encoding in the FileLogWriter to address an implicit log injection vulnerability.

When a user of log4go logs data that is potentially attacker controlled (for instance, they log some oddly formatted form data found in a web request) they allow attackers to manipulate those application logs by injecting invalid log entries.

A description of log injection with examples can be found here: https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b. I've created a test program with a concrete example of how a log injection attack would work against log4go in the examples directory. Please look at examples/LogInjectionExample.go.

A few design notes: . Log injection can generally be defended against with input validation or output encoding. Output encoding is more flexible because it can be used to defend against arbitrary types of inputs. This fix uses output encoding, replacing newline characters ('\n') with string literals ('\' followed by 'n'.) . Log injection can be fixed closer to the source of tainted data or closer to the output. Here I went with closer to the output. While newline characters are used in log4go to delimit log entries in text files, they are not necessarily used as such in other forms of logging such as socket logging. Perhaps in the future it will be wise to adapt this fix to be more flexible for different log destinations. . Because this fix changes potential output, I didn't want to make automatic newline encoding the default as a patch should never break compatibility if it can be avoided. As such, the ability to perform newline encoding is configuration driven and the default of this version is to not perform encoding. I suggest changing this in future major revisions of log4go.

Please feel free to reach out to me if you'd like to discuss these changes in greater detail. You can email me at werockthebodine@gmail.com.

Thanks!

Bodine Wilson

[jeanphorn]

@bodine actually, I am not good at security, but thanks for your advice to make this project better and safer.