IAST & the Villainous Library Named "commons-httpclient-3.1.jar"

Let’s talk about commons-httpclient-3.1.jar. I get asked about this library all the time.

It’s an HTTP communication library. 
It has a vulnerability in it.
It doesn’t handle SSL very well.

In fact, it doesn’t really verify you are who the client wants to talk to -- it just verifies that you are someone (re: anyone), who has any old SSL certificate. Basically, “haha SSL is off.”  Even worse, this library was a dependency used by Amazon and PayPal’s SDKs. At least those aren’t sensitive transactions, right? Well, they’re not the only ones caught up in this. Over 5700 other libraries currently rely on commons-httpclient-3.1.jar today. So even though you may not always be asking for it by name, you’re getting it a lot more than you think. Here is a sample of some other libraries that will come bundled with this infected library: 

• Spring Web
• Ehcache
• Log4j
• CXF
• Resteasy

Contrast Security monitors thousands of applications, so we thought we’d ask: just how common is this flawed library? The answer is astounding: This library is in 7% of all Java apps. 

Holy crap! SSL is broken everywhere! Developers, replace this library, stat! I don’t care how much work it is! No excuses! 

Ok, well, maybe that would be your next step if you only had static analysis. The IAST analysis is thankfully more nuanced.

How Does Contrast (with IAST Testing) Make This Better?

Static analysis can only see the code, so they can only see what libraries your app uses. But they can’t actually handle scanning your libraries, let alone attempt to understand how your app uses them. They can’t even accurately guess about how your code acts at runtime, let alone how your libraries act.

Contrast is different. We have sensors that trip when a library class gets loaded. Therefore, we can actually measure how much (and which parts) of a library get used -- all without the hassle of a 7-hour scan and 95% false positives.

The truth is, most libraries do a lot of different things. Dozens, or even hundreds of things. Almost all the time, the vulnerability associated with a library is just for one of the things it does -- not everything. 

On top of that, most libraries are not used at all. Our data shows that 78% of libraries are never even loaded. They’re dependencies of some other library that you’re using. Our data also says that folks only use 7.7% of the libraries deployed. 

So that “iceberg” picture, with a little cap of custom code on top and huge amounts of libraries and frameworks underneath, is misleading.  You’re only using 7.7% of that iceberg. If there are vulnerabilities in the other 92%, they don’t matter and you don’t need to panic. It’s more like your custom code is a beautiful oak tree, with some strong roots down into libraries and frameworks. 

Conclusion

Back to our our current villain, commons-httpclient-3.1.jar: about 48% of the applications that have it actually use it -- which is unusually high -- people do use this thing!

Even if static analysis could look for usage of a certain library in your code, that still wouldn’t be enough. Remember, libraries can (and often do) call into other libraries. So, because static can’t afford to look into what the libraries do, they’ll still miss almost everything. 

So basically, yes -- static analysis could tell you which libraries you have, and which have known vulnerabilities (if they have that feature.) Unfortunately, that’s just not enough data to make a smart decision. Without answering the question, “do I even use this library?,” you and your developers are going to be spending the vast majority of your time fixing things that aren’t problems.

Save yourself a lot of time, worry, and pain by trying an Interactive Application Security Testing (IAST) product like Contrast Assess.