This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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
I'd say the biggest thing would be that methods should throw exceptions rather than return error values. Java does this under many circumstances, but not all.
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.
David Svoboda wrote:I'd say the biggest thing would be that methods should throw exceptions rather than return error values. . . .
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.
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?
I will suggest that exceptions are much preferable over returning default values (such as null). When a program exits from a library function, the library loses the ability to control what happens next. A function that detects an error could return a default value, or set some static error variable (such as C's errno), but code that calls the function is free to ignore the default value or error indicator, and happily assume the function succeeded. This has caused many vulnerabilities like this Flash exploit.
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,
Joined: Oct 13, 2005
Do you think there would be a problem if your standalone program goes onto the web? If you have the sort of return‑null type of methods, do you have to change them to throw an Exception throughout? Particularly if those are checked Exceptions?
We are building functionality currently to allow for a cloud deployment (new customer wants it that way), so it will be very much out there once they go live. There is a lot of legacy stuff that (~12 years old or so) that would really benefit from a beating with the refactor stick, but as to how much we can get into scope that is a different question...
Joined: Oct 13, 2005
Of course, 12 years ago nobody had envisaged the Cloud.