1

I am looking for suggestions on tools/methods can be used to make sure , in java source code, sensitive information (like user password) is not accidentally been logged/printout .

user3774366
  • 53
  • 3
  • I'm looking for a good deal to the Caribbean. – Maroun Jun 25 '14 at 09:09
  • 1
    don't allow idiots to alter the code, and don't write silly mistakes in it. as soon as you have a developer "debugging" it, thinking that printing a password might help him fix anything faster and forgetting to remove that line, you're in trouble. – Stultuske Jun 25 '14 at 09:11
  • By definition you can not prevent of writing mistakes even if they are silly. – Damian Leszczyński - Vash Jun 25 '14 at 09:13

4 Answers4

1

You may specify some keywords for your critical variables and for their code behaviours. After that, you need to install findbugs plug-in and you may create a custom bug detector. Before you publish the app, run findbugs. It checks bugs and find them if exist.

Some examples are here :

http://lifelongprogrammer.blogspot.com.tr/2013/05/extending-findbugs-creating-our.html http://www.danielschneller.com/2007/04/findbugs-writing-custom-detectors-part.html http://findbugs.sourceforge.net/

Any other approach to protect your code, you have to obfusticate your code. (Not to printouts or logs, to protect your source code)

Good luck.

Tugrul
  • 1,760
  • 4
  • 24
  • 39
0

The do that you should be used some kind of Static Analysis tool. And check in their rule set.

For sure this kind of functionality is provided by Jtest (that is commercial tool). You can look on the FindBugs or even SonarQube.

For sure the tools will not be perfect and will not detect. The will try to be help full as much as possible.

But to 100% the best is the rule of four eyes. A code review by other developer might help. The Static Analysis tool should be treated as guardians for so called stupid mistake. A stupid mistake can be defined that is obvious when is pointed out. Everyone do them, so event having a review and general awareness in team there is chance to miss something.

Damian Leszczyński - Vash
  • 30,365
  • 9
  • 60
  • 95
  • that doesn't do anything. There's no magical way to detect whether something is "sensitive" and should not be used in certain ways. So you make a rule that variables named myPasswordField are not to be logged. I now copy the data from myPasswordField to myDummyTextField and log that. Nothing's going to notice that automagically, certainly not if I'm persistent enough and make the copy process convoluted enough. – jwenting Jun 25 '14 at 09:15
  • You have right about magic. You can apply a rule for naming of parameters as you suggested or you can also make rule on on methods. In case you have method `setPassword(hiden)` you can check at least two things. Is the hiden is printed out at some point or is the argument printed inside the method itself. The code should be self expression and the API should. I agree on statement that it will not be perfect. And that a part of static analysis be definition is not perfect and can apply some false positive or in this case positive false results. – Damian Leszczyński - Vash Jun 25 '14 at 09:53
  • But you can have a tool that will detect `logger(myPassword)` and this a benefit. – Damian Leszczyński - Vash Jun 25 '14 at 09:53
  • yes, you can. But it's not a benefit, it merely provides a false sense of security, which is worse than no security at all. People WILL find ways around it, and WILL use those. And not for mallicious reasons, merely because they have a need to for for example testing log that data. Better to have good procedures in place to ensure such statements don't make it into production code than to rely on some tool that makes you think you're good. – jwenting Jun 25 '14 at 10:39
  • This is topic for large debate. My opinion is that static analysis should be embedded in such process. As the build int imperfection it for sure not be only item in that process and not a prior one. But you can train, teach review and skip such thing as well. – Damian Leszczyński - Vash Jun 25 '14 at 10:45
0

From the code point of view, you want to be compartmentalising as much as reasonably possible. In static terms, the area of code that could access the sensitive information should be minimised. More importantly, scope of data should be minimised. In particular, no globals. No even logging. ("But logging is special!" No it isn't.) IIRC, "Growing Object-Oriented Software Guided by Tests" by Freeman and Pryce touches on what they call "auditing" rather static ad hoc loggers.

Everyone tests these days. A relevant testing technique is to use a known value for the sensitive data and mechanically search through files and network communications for that specific sequence.

If the format of the data is well defined, say credit card numbers, then this data can be scrubbed from the text output to log/audit files. It's not something that you would want to in anyway rely upon, but it could just save you.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
-1

There are no tools that can possibly automate that.
Instead, you need to have proper procedures in place for things like code reviews, and awareness among your programmers.

Just curious, how do you imagine such a tool working? How would it magically detect that something is sensitive and to what degree, and whether what's being done with it is or is not allowed?

jwenting
  • 5,505
  • 2
  • 25
  • 30
  • Java is not a good language for that purpose, but with a strong type system you could design restrictions that prevent printing sensitive data. It can't be perfect, as you have to define somewhere which inputs are to be considered sensitive, though. – Perseids Jun 25 '14 at 09:22
  • I really don't believe there is such kind of tool can provide 100% protection, at least with current technology capability. I am only looking for a secondary backup tool which may give some help. I agree that the best way to prevent information leak is by good code review procedure. – user3774366 Jun 25 '14 at 16:41