• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java Coding Guidelines Question

 
Ranch Hand
Posts: 104
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi to all the authors

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

Cheers,
S
 
Author
Posts: 13
5
Mac OS X Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Author
Posts: 11
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Stuie,

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.
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
David Svoboda
Author
Posts: 13
5
Mac OS X Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Stuie Clarky
Ranch Hand
Posts: 104
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all the responses everyone

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,

Stuie
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Stuie Clarky
Ranch Hand
Posts: 104
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...

Stuie
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Of course, 12 years ago nobody had envisaged the Cloud.
 
Stuie Clarky
Ranch Hand
Posts: 104
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are still parts in the bowels of the code base that were written pre Java 5
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is only a few years since people discussed Java1.3 code on this website. A lot of companies are scared to get rid of ten‑year‑old code in case the updating breaks the app.
 
Stuie Clarky
Ranch Hand
Posts: 104
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, we are slowly managing to refactor it out where there is time and testing budget. Just makes me sad when you build the project and get 80-90k worth of compiler warnings
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic