In "cyberspace"... no one can hear your database scream

    It's 2:34am, local time.  You're snoring up a storm after a hard day at the office.  You've patched all your servers, your lockdown scripts have been verified, and your IDS is humming along perfectly.  Oh, and by the way, someone named "R0kk1t" just stole your customer database.  A quick check of the "Security Dashboard" when you get in at 8:00am will show everything is green...  You have a serious problem.

    Sound like anyone you know?  This is a serious concern, and the problem is - it's pervasive.  It's scarry that 7 out of every 10 people I talk to about Web Application Security don't have any defenses.  When I ask what their defenses are they mention things like firewalls, IDSes, and patch policies - all have absolutely nothing to do with (and will do little for) Web Application Security.

    Houston - we have a problem.  Even if you're trying to build a program geared towards protecting your web apps - how are you going to justify it?  Inevitably someone is going to ask you the daunting question - "So, have we been attacked?  How many times?"  Odds are you're going to have no idea.  All hope is *not* lost though... I have some suggestions from years of this happening to me.  Here are some tips on building self-defense mechanisms into your web applications - and how to use them as rudimentary alerting triggers...

• Kick out the troublemakers - A well-built web application has to know when someone is just being stupid.  If your're tracking logged-in users it's even easier.  Track the per-user incidence of "bad data" and if it reaches a specific threshold - expire the session and send that user to a page warning them that they've been bad and must re-login.  It's basic, and not hard to do - but rarely implemented.  Of course, you'll have to figure out those thresholds and what "bad data" is - but at least you have a start here.
• Whitelist - In the point above I said you should track "bad data" or bad user-supplied input but how do you know what is good versus bad?  Simple, you first have to define what you should expect from the user.  An application should, on a per-page and per-input basis, know exactly what input is allowed and what data sets are in play.  You can use regular expressions to validate these lists!  For example, if you've got a field that expects social security numbers (don't we all) then you can have this simple bit of JavaScript to validate (obviously you'll want to do this on the server side!)

function isValidSSN(value) {
    var re = /^([0-6]\d{2}|7[0-6]\d|77[0-2])([ \-]?)(\d{2})\2(\d{4})$/;
    if (!re.test(value)) { return false; }
    var temp = value;
    if (value.indexOf("-") != -1) { temp = (value.split("-")).join(""); }
    if (value.indexOf(" ") != -1) { temp = (value.split(" ")).join(""); }
    if (temp.substring(0, 3) == "000") { return false; }
    if (temp.substring(3, 5) == "00") { return false; }
    if (temp.substring(5, 9) == "0000") { return false; }
    return true;
}   

• Log, Log, Log - Your web applications should always have a separate log file for "unexpected input".  In fact, where I've had input into the development process I've required there to be at least 2 log files.  First log file logs all "unexpected actions" in a web application, the time/date, the logged-in user, the source, user-agent and all other pertinent details of the "unexpected action" whether it be an exception, a crash, or whatever.  The second log file is just a dump of all the weird input people submit - some malicious, some not, to better help write regular expressions to filter the garbage.
• Fire Alerts - All the things I've mentioned previously are great - but if no one looks at them, or gets an alert when they fire - they're worthless.  Make sure you create actionable alerts from with your application framework.  Combine all the loggins, white-listing, and self-defense into something that you can understand.  Be careful of the information Monster though... if you're not careful in the way you set this up you'll end up with 10,000 emails/hour and won't be any more effective than having nothing.  It's a difficult balance but with practice you'll be one step closer.

Well - I hope you find those useful.  If you're willing to share, I would love to hear of some other methods that YOU are using in the real-world!  Leave them as a comment here, share with the community - remember we're all smarter when we share information.