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! :)