CODEWITHSUNDEEP
javaeclipse-pluginjettyfindbugssonarlint
kavetiraviteja
kavetiraviteja

Reputation: 2208

Warn on Logging security Info

I'm so worried about people logging confidential information to server logs. I have seen server logs in production. Some developers are accidentally logging security related information like password, clientId, clientSecret etc.

Is there any way, like Eclipse plugin or any tool, to warn developers while writing their code?

 `ex : log.info("usernam = " + username + "password = " + password) ;` // 
Warn that confidential info is getting logged.

I have done some research... I have seen tools like sonarLint and FindBug

but those plugins are unable to solve my problem.

Upvotes: 5

Views: 1856

Answers (5)

Charles Esau
Charles Esau

Reputation: 64

I wouldn't hold my breath for some out-of-the-box solution on this one. Beyond your own logging, you also have to be concerned about the logging done by your dependencies. That said, you have two areas to work on: what goes into the logs and who has access to the logs.

As far as what goes into the logs, your best tools to combat this problem are education and collaboration (including the aforementioned code reviews). Start with writing a list of non-functional requirements for logging that includes security that addresses what to log and how to log (markers, levels, sensitive parameters, etc). I recommend working with colleagues on defining this list so it doesn't become known as "Ravi's logging crusade" instead of "something we really need to do".

Once that list is defined and you get your colleague's and/or management's buy-in, you can write wrappers for logging implementations that support the list of non-functional logging requirements that you assembled. If it is really necessary to log sensitive parameters, provide a way for the parameters to be asymmetrically encrypted for later retrieval by a root account: such as the encryption key stored in a file only accessible by root/container. For management, you might have to spend some time writing up value propositions describing why your initiative is valuable to your company.

Next work with whoever defines your SLDC - make sure the change to your SDLC is outwardly communicated. Have them create a Secure Coding checklist for your company to implement with 1 item on it that says: All logging is implemented using OurCompanySecureLogger. Now you can start working on enforcing the initiative. I recommend writing a check on the build server that looks at dependencies and fails the build if it finds a direct reference to log4j, slf4j, logback, etc.

Regarding the other half of the problem, work with your SysOps team to define rules of Segregation of Duties. That is, software engineers shouldn't have access to the servers where logging is being performed. If you're not staffed well enough at this point to support this notion, you might have to get creative.

Upvotes: 1

Stephen C
Stephen C

Reputation: 718788

Another approach is to create a custom log appender that looks for certain tell-tale patterns (e.g. works like "password" and "passwd") and obliterates the messages, or throws an error.

However, this could be dangerous. If the bad guys knew you were doing this, they might try to exploit it to cover their tracks or even crash your server.

Upvotes: 2

Wohops
Wohops

Reputation: 3121

SonarLint offers the rule S2068: Credentials should not be hard-coded, which targets the use of hard-coded credentials, and it seems close to what you are trying to achieve, though it may be not enough for your needs.

As stated in other answers, however, identifying such security holes can be ultimately hard and strong code reviews is certainly a good move to reduce the risks.

Now, if you really fear about usages of loggers, already knows potential issues, and what data could leak, I would suggest to write your own Java Custom Rule for SonarQube.

Custom rules are supported by SonarLint and can be applied at enterprise level once the Custom Plugin containing it is deployed on a SonarQube server. This solution would allow you to explicitly define what you want to target, and fine-tune a rule depending on your needs and enterprise specifics. Writing such rules is not hard and documented in the following tutorial: Custom rules for Java.

Upvotes: 7

Harshit Thacker
Harshit Thacker

Reputation: 112

May be you should try Contrast tool. Its good one and we are using it since long.

It takes care of all updated owasp top 10 issues.

Quite good for finding security holes in enterprise applications.

Their support is also good.

Upvotes: -1

Sebastian Zartner
Sebastian Zartner

Reputation: 20105

There are many different ways how security holes can appear. Logging data to the browser console is only one of them.

And to my knowledge, there is no tool that can detect those security issues automatically. It is the responsibility of the programmer to not expose private user information on a page.

In this case the advice is: Never log passwords (especially unencrypted ones) to the browser console! Instead, encrypt your passwords in the database with an algorithm that can't be decrypted.

Upvotes: 3

Related Questions