Dhruv Mohindra

Author
+ Follow
since Dec 08, 2009
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
4
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dhruv Mohindra

Thanks for having us here and congratulations to the winners. Happy secure coding!
7 years ago
Hi Ted,

Ted North wrote:
Does the book cover any tests that can be done using some sort of tool that can analyze byte code or source code?



The JCG book consists of guidelines that are meant for a programmer to read. Guidelines differ from rules in that, sound automated analysis is not always possible. For example, a tool may not be able to determine programmer intent by inspecting bytecode or source code.

The CERT Oracle Secure Coding Standard for Java (AW, 2012) from the same group of authors consists of rules that are amenable to static analysis and useful if you intend to build secure and reliable Java based software. In fact, some of the rules have been adopted by these tools and converted to checkers / detectors.


Does the book show how to use vulnerability assessment software on a java program or web application?



Tool support is out of scope for the JCG book - such information is eternally changing and tool updates are frequent. The JCG book explains through example insecure and secure code but does not intend to provide a "security testing" strategy.
7 years ago
Hi Jeanne,
Thanks for your great reviews!

Jeanne Boyarsky wrote:Between "Java Coding Guideliness" and it's predecessor "The CERT Oracle Secure Coding Standard for Java", which one do you recommend people buy and why. And no saying "both."



One book contends in the heavyweight category while the other contends for the lightweight title!

I'd recommend the lightweight "Java Coding Guidelines" book because of the more intuitive classification of guidelines which gives you a feel of the message we are trying to get across. If you like what you see here, chances are that you would want to delve deeper into Java's rich set of features in which case you can look at the predecessor, "The CERT Oracle Secure Coding Standard for Java". The predecessor book groups together secure programming best practices by Java's various features and can be particularly useful for readers who want to understand how to use those features correctly and securely. Using them in conjunction can be quite effective too.
7 years ago
Hi Charlsy,

I would like to know what reliability is.



Reliability deals with the expectation from a system to operate according to its functional specification under some stated conditions for a specified time duration. Sometimes it is also referred to as the probability that software will not cause the system to fail under stated conditions for a specified time duration. The introduction to the "Reliability" chapter in our JCG book elaborates the software reliability aspect.

For a Java based web application, reliability could entail ensuring that webpages are served despite underlying coding bugs, runtime errors and most importantly issues caused by a deficient design / architecture. The first step towards meeting reliability requirements is to follow a coding standard and avoid writing sloppy code. The next step is to follow the principle of least astonishment - do not produce code that is complex, ambiguous, inconsistent or unpredictable. Code must also be written to avoid / address known failure scenarios in a fail-safe manner.

Does it have to do with how robust a say web application is in how it handles multiple requests without failing to serve jsp
pages?



For a web server, handling multiple requests without failing falls under "availability" (part of the security - CIA triad) as well as "reliability". An application server that runs without errors for X amount of time may be considered reliable. Also, note that reliable code will promote availability but a highly available system may not imply that the constituting code is reliable.

Does it have to do with how many times a recursive function can call itself without the program running out of memory?



A program that always runs out of memory because of recursion falls under "security" (denial of service). A program that occasionally runs out of memory (say every other hour) because of memory leaks or faulty concurrency is certainly not "reliable".




7 years ago
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.
7 years ago
Hi S G Ganesh,

S G Ganesh wrote:To the authors of the "Java Coding Guidelines" book: I saw the TOC of your interesting book, and I was not quite convinced that program understandability directly relates to security.
Yes, at a logical (or high-level), any violation of programming best practices is not a good thing since it may confuse the reader, the compiler, etc. that can lead to mistakes during fixes for example consequently leading to security vulnerabilities.
However, does program understandability directly relate to security vulnerabilities? Given the fact that you have devoted considerable number of guidelines in your book on program understandability, can you please clarify the relationship between program understandability and security?



Convoluted code has a bigger chance of harboring a vulnerability. Take for example the case where a developer constructs a bean class that has a private InputStream member and a corresponding getter/setter. To the unsuspecting, that may sound reasonable, however, resource management (closing the stream) is going to be very unwieldy in such a design. A clear separation of the data access logic and a clean data model would go a long way towards avoiding the denial of service vulnerability caused because of too many open input streams.

The interplay between program understandability and security is magnified in such scenarios.
7 years ago
Hi Ulf,

The distinction between the risk for an applet and servlet is definitely worth noting as you explained.

Ulf Dittmer wrote:

David Svoboda wrote:They only affect Web applet & servlet developers.


Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal.



Although it sounds overkill to sandbox web apps, it can provide an additional layer of defense. For example, in the scenario you cite above, a path traversal vulnerability in code could compromise the file system contents unless the application's IO access is specifically restricted to a folder or file through the use of a Java security policy and security manager. A hole in the sand-boxing mechanism would be detrimental in such cases.

7 years ago
Hi Wesley,

Wesley Womack wrote:Is the information in your book applicable to other JVM languages? I'm primarily interested in Groovy.



The JCG book specifically targets the Java platform. All the same, there's plenty of advice that carries forward to Groovy and Java-like languages. Groovy may require an additional set of best practices, but after reading this book it will be intuitive to apply the suggested concepts / recommendations to the programming language of your choice.
7 years ago
Hi Kent,

Kent O. Johnson wrote:
What brought you and the others to write this book at this time?



Back in 2008 we realized the need for a community vetted secure coding standard for developing secure Java based applications. This resulted in The CERT Oracle Secure Coding Standard for Java (AW, 2012). The rules were developed with community inputs on CERT's Secure Coding Wiki where they have always been available for free reading.

That said, we became equipped with evidence that there are a set of coding guidelines that if followed, result in more reliable and secure code that is also easier to maintain. This book is an effort to document best practices so that a reader becomes acquainted with the basic / advanced set of skills expected from a competent programmer.


What was the motivating factors that brought your group together to make this book happen? Was it a deficiency you saw in the current literature for Java in security?



We did an extensive literature survey and found pieces about Java best practices scattered across various papers, a few current and some dated books. Some of the sources were current and useful, however, we had to connect the dots to put together the book.

There are areas that have received less focus, for example, how do you groom an entry level programmer who has just finished school so that he can write enterprise grade code? One aim of the JCG book is to reach out to the eager learner and the practicing professional so that they can supplement their knowledge to build robust software.
7 years ago
Hi Saumyaraj,

Saumyaraj Zala wrote:Do this book cover the example of all security threats and when to use it?



This book (JCG) is split-up into five chapters - security, defensive programming, reliability, program understandability and programmer misconceptions. Each chapter consists of secure coding guidelines that can be applied to various Java based platforms such as Java EE and ME.

For each guideline, examples of insecure and secure code are provided to help with the identification of threat vectors and corresponding mitigation strategies. Some of the examples presented derive from real world programming anti-patterns while there are others that highlight recent JDK vulnerabilities and how they were fixed. Note that the coverage of programming best practices is broad and is not limited to security.

This book is a sequel to The CERT Oracle Secure Coding Standard for Java (Addison Wesley, 2012) which contains a base set of rules that are essential for developing secure and reliable Java based systems. The JCG book may be used in conjunction with that title for getting a more holistic picture of the Java secure coding space.

If you work with / lead a group that is doing anything serious with Java or are interested in exploring Java secure coding through example, these titles could be a good start.
7 years ago
Thanks for the warm welcome and feedback! Look forward to interacting with you all and answering your queries.
7 years ago