Java Coding Guidelines Question
I would like to know that if there was a single thing you could get developers to do that would have the greatest impact on improving the level and quality of security, what would it be? Was there a common recurring factor that kept resurfacing, either during writing the book or that you have seen professionally, that became a real 'bash-head-into-keyboard' moment for you?
Best of luck with the book, will be adding it to my reading list
For example, many of the File methods, such as File.mkdir() return a boolean indicating success. An all-too-common error is for code to call File.mkdir(), ignore the result, and then proceed to work with that directory. If mkdir() fails for some reason, then future code would misbehave. If you're lucky, you'll get an IOException somewhere, but not at mkdir() the failure really occured.
We address this more fully in FIO02-J. Detect and handle file-related errors from our first book.
The best advice I can give ten is: if your method might fail, and the failure might affect anyone who calls your function, then throw an exception. They can catch it if they don't care about failure.
Stuie Clarky wrote:
I would like to know that if there was a single thing you could get developers to do that would have the greatest impact on improving the level and quality of security, what would it be?
In the absence of a dedicated in-house or 3rd party security program, the single best thing I recommend for a development team is to incorporate a peer code review process and appoint a "champion" developer who has the additional responsibility of ensuring that the code makes the cut. It's always good to run a suite of security tools that can catch the low hanging fruit and let the security champion overhaul the overall awareness levels of the team through frequent knowledge-sharing sessions.
Was there a common recurring factor that kept resurfacing, either during writing the book or that you have seen professionally, that became a real 'bash-head-into-keyboard' moment for you?
It's always a challenge to code securely and get it right the first time. The bash-head moment occurs when any of our proposed secure solutions violates one of our own different guidelines, but luckily we can blame each other on those rare occasions.
If you have ever learnt any Eiffel™, you know that Eiffel™ methods have REQUIRE and ENSURE keywords, to enforce preconditions and postconditions. To use them you have to understand the concepts of class invariants and methods maintaining correctness.David Svoboda wrote:I'd say the biggest thing would be that methods should throw exceptions rather than return error values. . . .
Do you think returning default values as opposed to throwing Exceptions represents poor understanding of general Computer Science and maintaining the invariants?
We all know that C code tends to return or set error values and doesn't suppotr exceptions (at least I think so). I also suspect that some of the older features of Java® (e.g. the names of methods in the Math class are “borrowed” from C conventions. Is there any chance the methods like mkdir() are like that, being introduced without a complete understanding of Exceptions.
And now I have started asking naughty questions, is there a corresponding method in C#? Does that throw Exceptions in case of failure?
Java exceptions are a big win because they allow a library writer to divert control flow by throwing an exception. While caller code can catch and handle the exception (or even ignore it), this is not the default behavior. Novice programmers who invoke the library function without catching the exception will usually find their program terminated because they didn't handle an error condition.
From what has been said, it sounds like the company I work for is not doing too badly. We do have a fairly rigorous peer review system in place(we are required to get a technical reviewer and a functional reviewer to both approve before the commit is allowed), although I feel the focus is more on the code adhering to 'the standards' rather than security. Historically our product is very stand alone with little outside world interaction, but this is now slowly changing so I guess security should become more prominent.
Thanks again everyone,