Java security plagued by crappy docs, complex APIs, bad advice

Boffins bash stale Stack Overflow fixes and lazy developers

Relying on search engines to find answers to coding problems has become so common that two years ago it was suggested computer programming be renamed "googling Stack Overflow," in reference to the oft-visited coding community website.

But researchers from Virginia Tech contend more care needs to be taken when copying code from accepted Stack Overflow answers, at least in the context of Java.

In a paper released on Thursday titled "Secure Coding Practices in Java: Challenges and Vulnerabilities" [PDF], five computer boffins – Na Meng, Stefan Nagy, Daphne Yao, Wenjie Zhuang and Gustavo Arango Argoty – analyzed Stack Overflow posts related to Java security.

They found that many developers don't understand security well enough to implement it properly, that the overly complicated APIs in the Spring security framework and other libraries lead to frustration and errors, and that some popular Stack Overflow answers are unsafe and outdated.

"The significance of this work is that we provided empirical evidence for a significant number of alarming secure coding issues, which have not been previously reported," the paper says. "These issues are due to a variety of reasons, including the rapidly increasing need for enterprise security applications, the lack of security training in the software development workforce, and poorly designed security libraries."

The researchers analyzed 497 Stack Overflow posts related to Java security because, they said, the site is popular with developers and plays an important role in educating them.

They looked at common concerns related to secure Java coding, common development challenges, and common security vulnerabilities.

And they found that many of the answers endorsed by the Stack Overflow community led to insecure code. For example, accepted answers often recommended the use of MD5 and SHA-1 crypto algorithms – despite the fact that they're insecure and should not be used.

Stack Overflow answers also recommended trusting all SSL/TLS certificates to bypass cert verification errors, even though this disables SSL security checks.

Similarly, advice related to implementing authentication in Spring suggested disabling Cross-Site Request Forgery checks.

The researchers had nothing nice to say about Spring, which accounted for 55 per cent of the Java security implementation questions that were analyzed.

"We provided substantial empirical evidences showing that APIs in Spring security (designed for enterprise security applications) are overly complicated and poorly documented, and error reports from runtime systems cause confusion," the paper states.

They also observed that in some instances, the higher social reputation of Stack Overflow respondents led to incorrect answers being accepted over more correct fixes offered by individuals with lesser reputation scores.

'Resist the urge to apply solutions'

Library designers, the paper advises, should remove or deprecate APIs with weak security, like MD5. And tool builders should develop more automated security checking capabilities.

The paper recommends that developers spend more time testing security features, avoid disabling security checks, and exercise caution with community answers.

And it advises StackOverflow admins to think about how outdated posts get presented, because of the perils of unsafe code.

"There is always a risk when developers use code they do not fully understand," said Josh Heyer, community management team lead for Stack Overflow, in an email to The Register.

"We encourage all programmers looking to benefit from the guidance found on Stack Overflow to resist the urge to apply solutions to their work without first reading the full answer, other answers to the same question, and any warnings left as comments by previous readers."

Heyer said developers should always refer back to official documentation when using an unfamiliar API for the first time, noting that the most trustworthy community-based answers tend to cite the docs.

tl;dr RTFM. ®