Java Security Traps Getting Worse
The never ending battle to get Sun to DO SOMETHING about their Java 'product' is NOT OVER
From : Java Security Traps Getting Worse
A year ago at JavaOne, Fortify Software Founder and Chief Scientist Brian Chess gave a presentation titled "12 Java Technology Security Traps and How to Avoid Them."A year later, how far have we come in addressing those inherent vulnerabilities, which include XSS (cross-site scripting), SQL injection and native methods that allow the import of C or C++ code—along with its bugs? Not a smidge—unless you count going backwards.
It's gotten worse, Chess said in an interview with eWEEK, "and I've got evidence to prove it."
Fortify, which markets source-code analysis technology, has access to a large database of common Java programming errors and vulnerabilities, gleaned not only from its customers but also from a year of running the Java Open Review project.
In that project, Fortify uses FindBugs, a static analysis tool that looks for bugs in Java code, to look over code in open-source projects such as Apache, Azureus and Tomcat. Fortify does an analysis on each inspected code set, publishes online how many issues it finds and then shares with project maintainers the vulnerability specifics.
What Fortify has found from running the project is that the defect density of open-source code is "astronomical," Chess said, pointing out one project in particular that Fortify has inspected over the past year: Net Trust, with an estimated 12.215 errors per 1,000 lines of code.
"That's huge for a project with 'trust' in its name," Chess said.
Ironically enough, Net Trust is a Google project to create a security mechanism for simple single sign-on and authentication. "But they were students doing not very good code," Chess said.
Net Trust is one of many examples that demonstrate that Java security traps, although known for some time, are snaring more programmers all the time as use of the language grows.
To illustrate the lack of secure coding instruction, Chess points to a recent find he made, from none less than the Java giant, Sun. Specifically, the Sun introduction to servlet programming (Sun's simplest method for hooking Java up to the Web) contains cross-site scripting vulnerabilities.One example of an XSS vulnerability are these lines from Sun's instructions:
try { firstname = request.getParameter("firstname"); } catch (Exception
e) { e.printStackTrace(); }
userName = firstname;
...
pw.print("
Thanks for your feedback, " + userName + "!
");This code allows an attacker to inject code into the application that will be executed on a victim's browser, Chess said.
"The code expects that a user has entered a name like this: Bob," Chess wrote in an e-mail exchange. "But an attacker could set it up so that the data looks like this: and then the victim's browser would execute a function named sendDataToMotherShip()."
A secure version of the server-side code, Chess said, would check input to make sure that it only contains an expected set of characters and no executable scripts.
"SQL injection problems still do sit at the top of the list" of Java security traps, he said. "[Developers are] trusting input they shouldn't trust."
If this is coming from Sun, who can we trust? "You'll see that the tutorial never mentions security," Chess said. "With that in mind, it's not surprising that it contains cross-site scripting vulnerabilities."