Saturday, December 8, 2007

Input Validaton Rant

When should we do input validation in J2EE applications?

I can think of 3 scenarios all with their own trade-offs.

1) "Let's just skip validation inside the application, and apply a few J2EE filters before we deploy. "

This is the solution I've been forced down in the past. I'm not a fan. It's not fair to be in a situation where the coder has the responsibility, but not so much the power. J2EE filters, while still being Java code, are external to the core app. I think of J2EE filters as part of the configuration layer; not integrated deep into the app itself.

Now, there are occasions where adding a filter (such as Eric Sheridan's CSRFGuard) is completely external to the app. The programmer never even needs to think about this kind of vulnerability if CSRFGuard is deployed. However, validation of a form element to ensure that it's a proper email address really seems like programmer responsibility to me. But adding a configuration filter like CSRFGuard to modify all forms by adding form keys really does not seem like programmer responsibility to be, but the platforms responsibility. When are we going to see work like CSRFGuard and the OWASP ESAPI project integrated deeper into J2EE, Sun?!

2) "Let's just start using Struts XML ActionForm configuration, have programmers completely skip doing any kind of validation, and have a AppSec regex professional work with our architect to set up configuration."

This has significant benefits, and I'm a fan of this methodology for big teams. But do not be lulled into a false sense to security just because you might have your input validation dialed in. Strong input validation does not protect you from security design flaws and a host of other attack vectors. But still, Struts input validation configuration at the XML level can be very powerful if done completely across the entire app. (each and every form element.) But you better have some serious regEx experience in-house, and have a regEx expert who is very much willing to take the time to learn the application as deeply as the folks who wrote it.

3) Let's do white list validation inside our controllers' dispatchers the moment we get data from the request.

This is my favorite, because I'm a manicoder.

[rant]
With the exception of Dinis Cruz, everyone in the industry is blaming the coders. http://reddevnews.com/features/article.aspx?editorialsid=2386 (Thank you, Dinis) Yes, we are often the scapegoat (baaaaaaaaah!) being asked to write code faster, cram more functionality in, and get it done before some arbitrary date passes. And we have wonderful people like Alan Paller "expressing frustration with the fact that everything on the [SANS Institute Top 20 Internet Security] vulnerability list is a result of poor coding, testing and sloppy software engineering."

Thanks Alan; but when are executives like you going to really invest the time, energy, money, training, Q/A resource and longer development cycles to truly allow us manicoders to engineer secure applications? Blaming the coder is an easy way out; Application Security policy, money and time needs to come from the top down. And this is a very tough sell when all you get out of it is insurance and assurance that is still very difficult to mathematically prove correct. If you have programmers in you org who are writing insecure code, I conjecture that we need to look at the "C-level" and see how much they truly care about this topic and take note if they are willing to commit to the cost and time necessary to win the battle of secure code.

We can't just blame the likes of Alan, even Gartner is telling the "C-level" that "developers need to take more responsibility" http://news.zdnet.co.uk/security/0,1000000189,39291194,00.htm thereby taking responsibility off the hands of the C's. Again, so unfair, when even Michael Howard at Microsoft with an almost unlimited hiring budget says that even the best and the brightest minds coming out of college have "no idea" now to write secure applications. http://searchsoftwarequality.techtarget.com/qna/0,289202,sid92_gci1283745,00.html?track=sy280&asrc=RSS_RSS-25_280

Let's kick it up another notch.

Right now, coders with security awareness are the "high priests" of software engineering groups. It does not have to be this way, but that is the truth in most organizations. AppSec knowledge is not integrated well into most organizations yet. And sadly, those coders who do have solid AppSec awareness and ability need to apply best-practice security guidelines **IN OPPOSITION TO UPPER MANAGEMENTS DESIRE TO DEPLOY CODE FAST**

If you really want to put the responsibility of AppSec into the hand of me, the coder, than we cannot depend on external configuration to lock down our apps. If you really want me to add IDS type logging deep within the bowels of my code, then you need to both empower me with training, tools and time to do so. This AppSec squeeze-play from the C-level needs to end.
[/rant]

Ok, back to input validation. I want control over my application at the absolute soonest possible situation when user input enters my code. I want to make sure strong whitelist validation is applied at the earliest point of entry into my code. I want to empower an auditor to easily dig through my code, look for every situation where we do request.getParemter and the like, and see whitelist validation applied right there and then, without having to dig through 10 other files or some elaborate platform technology to ensure proper validation is being done.

Thanks kindly for reading this far. For more information, contact Aspect Security for all of your appSec training, assurance and acceleration needs! :)

2 comments:

Stephen said...

As a "C", I try to coach upcoming "c"s in the class I maintain and instruct, SANS Security Leadership Essentials, that we need to explain to all the passionate department heads to "take a number".

It's not that you are wrong Jim; from your perspective you are spot on. But what is the company killer? Application flaws? I don't think so. I think next week the majority of "C"s are trying to figure out just exactly how exposed they are to the subprime disaster. The Garden Island Newspaper, my favorite source for financial news, carried a story today about groups in Florida that can't pay their bills because they had their money running through state government "safe" mortgage backed securities fund to pick up some float. According to the story, everything seemed great until November and the fund has already decreased by half. Someone is going to be sucking on the short straw.

Risk, the probability that a threat will cross a vulnerability is a funny thing, invariably it is the thing you didn't think to worry about and begin to mitigate that bites you bad. There is a book called Black Swan that makes this point pretty well.

Nuff said, congratulations on setting a wedding date, bout time.

Jim Manico said...

Hah, thanks for posting. I can't believe people actually read this blog, thanks Stephen.

It's easy to be right from my own perspective; but I'm hoping to make a more global point. The more you tell your coding staff to "take a number" regarding App Security the more you brush this problem under the rug and will end up taking a hit like TJMAX and and the like. You can't just throw a WAF on top of your apps, which is what plenty of managers will tell you. You need to fix the problem at the root and that requires code changes.

I also an curious as to your definition of Risk as "the probability that a threat will cross a vulnerability" I see it more as a x/y graph of IMPACT OF VULNERABILITY vs. the LIKELIHOOD OF THE VULNERABILITY, the key difference is that risk is only relevant in terms of how it impacts a business in some way. But I know risk can be measured in many ways, and I'm grateful you took the time to post.

I have the pleasure of teaching a application security leadership course for Aspect Security on occasion. We are very cost effective for organizations of any size, and we try to keep away from abstract theory and focus on real world hands-on labs to help managers comprehend the problems of application security right down to the individual lines of code without overwhelming them with to much information. It's a great thrill to see managers eyes light up when demonstrating a complex SQL injection vulnerability, then reviewing the code that actually caused this problem, the fixing and reploying the code right there in the moment, and then actually demonstrating that it truly was fixed. I think this kind of hands-on training, the hallmark of Aspect Security's training methology, really helps leaders implement deeper AppSec processes all throughout their organizations in a way that is gentle on their budgets.

I'm thrilled to be getting married, if only the programmers I worked with had as much security awareness as my fiancee. She called me recently to tell me that her firewall was chirping for an update and was not going to use the net until she talked about it with me. How can you not love a woman who has that kind of security awareness? :)