1

I'd like to have secure logging in my application, so that:

  • if I log something, the logging function should return happily if and only if the loggging was successful
  • the logfile should not be manipulated easily, so I should easily spot if someone
    • deletes from the logfile
    • alters the logfile
    • creates new entries to the logfile

So something, which reliably logs to a file with PKCS should suffice.

Is there a library which suit my needs, or should I write one from scratch?

EDIT Application is on server.

pihentagy
  • 5,975
  • 9
  • 39
  • 58
  • I would set the permission on the file so that someone cannot alter this way in the first place. – Peter Lawrey May 31 '11 at 10:23
  • If you just mean logging to a file, then, it's probably not any more secure than "normal" logging (you are relying on the OS permissions). You could try [this](http://jsexton0.blogspot.com/2010/03/image-via-wikipedia-java.html) to log via SSL over the network, perhaps... – michael May 31 '11 at 10:27
  • 1
    http://stackoverflow.com/questions/3778281/business-audit-log-recommended-library-or-approach/4055471#4055471 – sarnold May 31 '11 at 10:28
  • @michael_n: AFAIK there is no way to verify that a message is successfully logged or not. – pihentagy May 31 '11 at 12:25
  • @sarnold: +1, nice find, but I'll try to find free alternatives – pihentagy May 31 '11 at 12:27
  • You may consider [this](https://blog.konstantinpavlov.net/2015/07/26/secure-java-logging-with-logback/) – Konstantin Pavlov Aug 01 '15 at 17:13

2 Answers2

1

Take a look at the OWASP ESAPI Java library. It has a Log4J compatible Logger that will escape log output and strip out carriage returns for you. It can also be configured to output unique transaction and session IDs to avoid logging a user's actual container session ID.

braveterry
  • 3,724
  • 8
  • 47
  • 59
1

Taking the second requirement first, to provide integrity protection you need to either sign the log messages or generate an HMAC of the messages. That in turn requires that the app have access to either a private key for signing or a symmetric key for generating authentication codes.

That, in turn, means that you need to limit access to your app so that the key can't be extracted from it. This means that you've gone from trusting the access control on the log file to trusting the access control on your application. Compromised access to the application still allows third parties to modify your log file in a 'supported' fashion.

You can possibly, depending on the structure of your application and how it's deployed, use Mandatory Access Controls on the log file to make it append-only to users of the app, to mitigate the possibility of tampering or removing existing messages. You could additionally take periodic backups of the log file, and compare the content to ensure that nothing has been changed or removed between backups. This assumes that access to your backups is also controlled - a third party who can tamper with your backups can tamper with your log files in an undetectable fashion.

You didn't mention whether the application is on a server, desktop or smartphone, so the specifics of such access control aren't in scope for this answer.

As far as ensuring that a message has been successfully written before the app continues is concerned, Apache's log4j contains appenders that support this M.O. (just don't wrap them in AsyncAppender…)