Catch Secrets Written to Logging

Plaintext secrets written to a log file are a well-known vulnerability. Once an intruder gains access to a hard disk they can easily comb through log files to further exploit the system. Here a Business Transaction is used to search logging output to look for secrets.

Application data slips into logging in a variety of ways: lack of communication regarding which data is a secret, lingering early code, perhaps before a comprehensive logging strategy has been implemented, old debug statements or perhaps inadvertent inclusion via localization processing.

It’s a good idea to grep log files after your test run but that will not cover output to the server console, which may contain different content. For example, users may start the application using nohup which may write terminal logging to nohup.out. And starting an application with redirection of stdout and stderr will persist console output to a file, such as:

Continue reading the full blog post ...

What are the overheads? And seems like an unoptimal approach.......

With security manager enabled, you just have to store your "secret" into java.security.Guard as soon as you get it from user and then any access to that information requires a permission in your java.policy file.

If the first step is properly implemented, there should be no leak later in usage as far as permissions in policy are as limited as possible.

WebORB for Java now makes it easy for developers to provide Silverlight/Windows Phone 7 access to Java POJOs, EJBs, Spring Beans, Grails and XML Web Services. WebORB includes many developer productivity tools, such as Service Browser, Code Generators, Invocation Test Drive, and APIs for remoting and messaging, which are all designed to expedite development of client-server applications.