Year Of Security for Java – Week 13 – Know Your Frameworks

No Gravatar

What is it and why should I care?
Libraries and frameworks are a reality for every J2EE developer (pretty much any developer, actually) out there. We use them for MVC, DB, logging, web services, security, XML processing, as well as a host of other features. We rely on them in our production apps every single day. All this code written by someone else. Code that likely hasn’t been internally vetted. Code that likely hasn’t even been looked at. Yet, we still use these masses of code (generally MUCH larger than the custom code written for the app itself) to add functionality to our applications.

Knowing your frameworks means you don’t accept the code blindly. When you include a piece of software in your application, you’ve inherited and are now responsible for it. From a functionality perspective, you fix it when it breaks. From a security perspective, you are now responsible for dealing with it’s vulnerabilities. This is the crux of the problem: we manage a LOT of code now (code we didn’t write) and are responsible for making sure it is functional and secure: no easy task.

What should I do about it?
There are many things you should do when dealing with frameworks. I’ll cover the two I think are most important.

First, you should patch your frameworks when new vulnerabilities are found. This is a significant effort because it obviously requires much testing and coordination to upgrade frameworks within applications. However, there have been significant vulnerabilities found in libraries that are extremely popular, and that necessitates patching. Sometimes, patching can be done without upgrading the library actually. It could be moved off to a WAF or some such product. The point is you need to prevent the vulnerability that’s been exposed.

Second, you should really know and understand how your framework functions. While most frameworks patch vulnerabilities reasonably quickly (especially if the vuln public knowledge), they will often not patch their “design decisions”. These are often architectural patterns that benefit functionality, but not security. One popular pattern that comes to mind is auto-binding / mass assignment. The technique of populating the model using request data is not new, and is very powerful. It can make code much easier and cleaner to write. However, it’s often implemented with no security at all. The best you’ll usually get is an opt-in mechanism for securing it. However, most people are not going to opt-in, so it will be used insecurely in many cases. Patterns like this are frequently seen in modern frameworks, and developers really need to be aware of what’s going on internally in the framework to understand how the security and functionality of their application is going to be affected.

Frameworks are a necessary piece to most any development work going on today, but blindly trusting them is not. Be aware of what the frameworks you’re using do and how they do it. Keep an eye on them and patch them as necessary. This will help manage the risk of using them in your applications.

This post turned out to be very timely. Aspect Security just put out a nice paper (sorry, behind registration wall) on some analysis they did regarding the usage of java libraries through the maven central repo. They analyzed 113 million downloads and found that 26% of those downloads have known vulnerabilities! That’s a significant number. Their analysis doesn’t say whether or not those downloads were followed by requests for the patched versions, but I would bet not.


Be Sociable, Share!

Technorati Tags: , , , , , ,