I’m back with another book review. This time I’ll be reviewing Java Coding Guidelines by Fred Long, et al. This is sort of the 2nd edition of The CERT Oracle Secure Coding Standard for Java. I had previously done a review on the “1st edition” and was asked to follow up with a review on this latest edition. I must say, I enjoyed this version much more. It’s substantially shorter, better organized, and to the point.
TL;DR » Java has had a bad rap for security lately (particularly around it’s ancient Applet technology).
Read chapter 1 to learn how to become a more secure Java Developer. Read the remaining chapters to learn how to become a better Java developer overall.
About the Book: Audience, Skill Level, Prerequisites
The subtitle for this book is
"75 Recommendations for Reliable and Secure Program."
It’s an accurate description with one chapter on security and the remaining three chapters on reliability. This book is geared towards professional Java developers and goes through many of the idiosyncrasies of Java that you have to watch out for. Some of those idiosyncrasies can lead to catastrophic bugs and vulnerabilities, others may just lead to many hours of annoying-debugging-only-to-find-out-that-you’ve-done-something-really-really-stupid™ ;). I’d recommend that you’ve had experience programming Java for 1 to 2 years before you read this as anything before that and you might not fully grasp the importance of some of the recommendations.
Thoughts on the book
I think a better name for this book would have been, “How to be a Extremely Paranoid, Secure, and Awesome Java Developer.”
This book is all about dotting your i’s and crossing your t’s. Similar to how I mentioned that the previous edition was like Josh Bloch’s Effective Java, this book is all about teaching you how to a be a better Java developer and how to avoid mistakes that only a seasoned Java developer would know. Given that my day job is being a Software Engineer, programing in Java, I plan to hold on to this book at my desk for a couple of reasons.
- Whenever I need to teach a junior developer about “a bad way of doing things,” I can pull out this book and refer them to an example, along with a compliant solution.
- I can lend it to junior developers looking to improve and learn more.
Side note: Shout out to the Authors for using Utah (my home state) in their #8 recommendation: Prevent XPath Injection. Come visit and hit the slopes some time ;)
Applicability to Security
Given that the focus of this blog is on computer security, I’ll touch on the security points throughout the book.
Chapter 1 is all about security. Many of the recommendations are general security advice with an example of how they’d apply in Java. There are some interesting recommendations that are more Java specific though.
Recommendation #18: "Do not expose methods that use reduced-security checks to unstrusted code,"
is particularly interesting as this recommendation actually has real applicability. Failure to follow this recommendation resulted in a couple of CVE’s (CVE-2012-4681, CVE-2013-0422).
Outside of the explicit chapter on security, you actually might be amazed at how a seemingly minor bug or action can result in a serious security vulnerability. There are a couple of examples worth mentioning.
Recommendation #46: "Do not serialize direct handles to system resources."
In retrospect, this one seems glaringly obvious, however, I had never given any thought to it. Essentially, if you serialize a Java object, that opens a file, to disk, you can edit the bytes representing the object to change what file is accessed when the file is deserialized. The first thing that comes to mind with this is Minecraft. It’d be interesting to see if anyone has ever leveraged this for exploitation.
The other interesting recommendation is
Recommendation #52: "Avoid in-band error indicators."
At first, this one doesn’t seem like it’s that big of a deal, however, it has resulted in many security vulnerabilities over the years. What it recommends, is to not return values that represent an error, and instead throw an Exception. The reason for this is that calling code often does not check for failing return values resulting in the succeeding code accessing a file or data that may be in an inconsistent state. This type of vulnerability is leftover from the earlier languages like ‘C’ which would return -1 or other negative values to indicate an error.
Conclusion
Overall, great book and easy book to read if you’re familiar with Java. Final rating, 4.5 out of 5. Dustin