Modern enterprise applications are increasingly the result of developers cobbling together a variety of open source...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
components and frameworks to form a cohesive whole, with surprisingly little original code.
While that approach can reduce development time and costs, a researcher has found that the use of open source development frameworks can also mean inheriting unknown security risks.
Benjamin Watson, managing security consultant with Atlanta-based VerSprite Security Inc., has spent several months researching some of the framework security issues plaguing open source development components. His initial research focused on some of the most popular open source Java frameworks, like Spring and Struts, but Watson quickly discovered that many researchers had extensively documented the problems with those frameworks, though they remain as vulnerable as ever.
What makes the vulnerabilities in the Java frameworks noteworthy, said Watson, is that they result from inherent defaults in the frameworks, not mistakes by developers.
"These are vulnerabilities that the developers [who] use them don't actually write into the code," Watson said. In fact, the library or larger frameworks themselves are built with flaws that many developers never realize exist, he added.
Recent statistics from secure software development vendor Sonatype Inc. showed that open source components and frameworks now make up more than 80% of a typical application. Considering the widespread nature of such development components, Watson said problems related to flawed frameworks are likely to emerge in enterprise settings.
"Building a large-scale enterprise application, most of that stuff isn't completely written organically, so it's very easy to take things like Spring or Struts and build your application on top of them," said Watson. "But I realized after a while that the development community using these frameworks really had no idea that they were taking these things and implementing them with a lot of risks."
Serialization vulnerabilities come to JSON
Though Java framework security vulnerabilities have long been under the security community's spotlight, Watson wondered what flaws may be inherent in other popular developer components.
For instance, a Web page may serialize data gathered when a user creates a new profile that includes information such as name, gender, location and other pertinent details. The serialized data is stored in a cookie like JSON, said Watson, and whenever a user views the profile, the cookie is sent to the application server and the data is deserialized to determine the identity of the user and any related account permissions associated with the user.
The problem, he noted, is that if attackers could gain control of the object inside JSON that gets serialized and deserialized in the application, they may be able to control those permissions and the resulting data that can be accessed through the application. The json-io library allows developers to build an object in such a way that the field with the JSON string can be manipulated when it is deserialized, Watson added.
To prove his theory, Watson created an application that allows a user to create such a profile, but also includes a field that the user can't control, that allows administrator-level permissions by default. By modifying the JSON string and the cookie via json-io, a new object can be created during the serialization process that allows the user to become an administrator -- the vulnerability essentially allowing a savvy attacker unfettered access.
Watson admitted that he couldn't think of many valid abuse cases stemming from the JSON research, but that serialization vulnerabilities involving the JSON format and objects have not been extensively researched in the past. The problem isn't unique to JSON either.
"The concept of taking untrusted data and then serializing it is not new at all. In fact, it's been around for a long time as a vulnerability class, but not necessarily serialization vulnerabilities from JSON to objects. That class is kind of a little different," said Watson. "I was looking through Python and PHP, and noticed both of those languages have libraries that allow you to do the exact same thing."
Though json-io and other open-source libraries may feature serialization vulnerabilities, Watson added that at least with Java, a developer can mark fields as transient so that they won't be subjected to the serialization process -- effectively barring an attacker from modifying the field. More generally, he said that developers need to remember that an untrusted source may modify any data, and as such, there should be a thorough sanitization process for such fields.
As for how to eliminate such issues going forward, Watson said he would like to see more security mechanisms put into development frameworks themselves, or at least documentation warning developers that open-source components may still include vulnerabilities that need to be addressed. More importantly, he said that the security community must do a better job educating developers on the security risks they may be inheriting.
"You've been educated or you haven't, and when it comes to this class of vulnerabilities, some people understand the ramifications of doing A, B or C, and then some are completely oblivious," said Watson. "I think the development community is becoming aware, and the security community is doing an OK job of educating, but a lot of it has to be rooted in the security community and the development community coming together."
The recent Heartbleed OpenSSL vulnerability raised numerous concerns around the security of open-source software and applications. In the wake of Heartbleed, resident expert Michael Cobb details the potential security problems posed by open-source software, and how enterprises can more safely use such components.