Web application security is a hot topic, no doubting that these days.  The awareness is growing and developers are starting to take notice of the security shortfalls in their code.  Awareness of attacks like SQL injection, cross-site scripting, and CSRF (Cross-Site Request Forgery) is starting to spread and so are ways to protect against these types of attacks.

 With this Security 101 post I'd like to call attention to a particular type of attack that (after nearly 5 years of executing it successfully) is finally starting to trend towards extinction - but sadly still is all-too-common.  Let's do this by example...

  As you visit your favorite site one of the first thing that the server on the other end of your connection does is checks your browser.  It does this for an obvious reason: it needs to know whether to serve you java or ActiveX/.Net -based content.  This isn't going to go away since I don't see either Microsoft or Mozilla dropping out of the browser game, so the checking of "user-agent" will continue. Moving on in our example, the server pulls the "user-Agent" header component and has to compare it against known types of browsers.  Now, there are a number of ways that the server can check your browser version (against an XML file, using JavaScript from within the page, or using a database call) but it is fairly likely that it will be done with a database call to the back-end database server against a table of supported browsers.  Here's where the magic happens if you're an attacker.  Most of the time, if the developer is making a database call to check browser version compatibility they are *not* sanitizing that parameter before passing it into the database server.  This, of course, leads to SQL Injection.

  This absolutely fundamental check can cause a site or application with *zero form inputs* to still be vulnerable to SQL Injection.  I've seen it first-hand, so I know it exists in "the wild". Absolutely fascinating since I've had developers ask me why they need to sanitize parameters when they have little (or no) form inputs on a site.  My answer is always this example.

  The moral of this story is don't get over-confident.  Just because your site/application is 'basic' or short of complex inputs it does not necessarily mean that you're invulnerable to attacks like SQL Injection.  Check and sanitize all your parameters coming from the user-side.  Never, ever, under any circumstances trust data coming from the client.  This goes for *any* data, including header fields!