Security Warnings

Question

I am so worried that people are logging sensitive information in server logs . I saw server logs in production. Some developers accidentally register security-related issues such as password, clientId, clientSecret, etc.

Is there a way, such as an Eclipse plugin or any tool, to warn developers when writing code?

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

I did some research ... I saw tools like sonarLint and FindBug

but these plugins cannot solve my problem.

Answer 1

SonarLint proposes rule S2068: credentials do not have to be hardcoded that are designed to use hard-coded credentials, and this seems close to what you are trying to achieve, although this may not be enough for your needs.

However, as pointed out in other answers, identifying such security holes can be ultimately complicated, and reliable code checks are certainly a good step to reduce risks.

Now, if you are really afraid of using registrars, already know potential problems and what data may leak, I would suggest writing your own Java Custom Rule for SonarQube.

Custom rules are supported by SonarLint and can be applied at the enterprise level after the custom plug-in containing it is deployed on the SonarQube server. This solution will allow you to clearly determine what you want to target, and fine-tune the rule depending on your needs and the characteristics of the enterprise. Writing such rules is not difficult and is documented in the following tutorial: Custom rules for Java .

Answer 2

There are many different ways to detect security events. Writing data to the browser console is only one of them.

And, as far as I know, there is no tool to automatically detect these security problems. The user must not display the user's private information on the page.

In this case, a tip: Never write passwords (especially unencrypted) to your browser console! Instead, encrypt your passwords in the database using an algorithm that cannot be decrypted.

Answer 3

I would not hold my breath for some kind of ready-made solution on this. Aside from your own logging, you should also be concerned about the logging done by your dependencies. However, you have two areas for work: what is included in the magazines and who has access to the magazines.

For magazines, your best tools to deal with this issue are education and collaboration (including the aforementioned code reviews). Start by writing a list of non-functional requirements for logging, which includes security that takes into account what needs to be recorded and how to register (markers, levels, sensitive parameters, etc.). I recommend working with colleagues to define this list so that it does not become known as "Ravi logging crusade" instead of "something we really need to do."

Once this list is defined and you get the participation of your colleague and / or management, you can write wrappers for logging implementations that support the list of broken registration requirements that you have compiled. If it is really necessary to register sensitive parameters, provide a method for asymmetric encryption of parameters for subsequent retrieval by the root account: for example, the encryption key stored in a file, accessible only to root / container. To manage, you may need to spend some time creating value propositions that describe why your initiative is valuable to your company.

The next work with whoever defines your SLDC is to make sure that the changes to the SDLC are passed inward. Ask them to create a secure coding checklist for your company to implement with 1 paragraph on it, which reads: All logging is implemented using OurCompanySecureLogger. Now you can start work on securing the initiative. I recommend writing a check on the build server that looks at the dependencies and does not complete the build if it finds a direct link to log4j, slf4j, logback, etc.

For the other half of the problem, work with the SysOps team to define separation of duties rules. That is, software developers should not have access to the servers that are logging. If you are not well prepared at this point to support this concept, you may need to be creative.

Answer 4

Maybe you should try the Contrast tool. Its good and we have been using it since ancient times.

He takes care of all updated 10 owasp issues.

Very good for finding holes in enterprise applications.

Their support is also good.

Answer 5

Another approach is to create a custom logging application that looks for specific control patterns (for example, acts as a “password” and “password”) and destroys messages or generates an error.

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