Field Validation Stupidity
I have seem a lot of examples recently where, in form validation, companies put all their eggs in the Javascript basket for validation. While for 99% of the user base of these forms is probably going to be quite effective there are some gaping exceptions that leave these companies open to all manner hacks. In my simple mind if you fail to validate your form input on the server side you are assuming one or more of the following:
- People are basically good (yeah right)
- Nobody is going to hack me (how arrogant)
- You can only submit the form one way (wrong, think curl et. al.)
- My Javascript will catch errors (and if its turned off in the browser?)
There are probably some other assumptions but those are probably the worst. So you ask, what can be done to protect my server?
First off do an input sanity check if you are expecting an integer from a field make sure that’s what you have, same goes for an email address, etc… Keep in mind that when doing input sanity checking that you stay flexible, for example if you ask for a phone number take: (123) 555-1212 or 123.555.1212 or 1235551212 or 123 555 1212 or (ad nauseum…). Don’t compromise your user experience because you are too lazy to write a good validation routine.
Secondly make sure you strip out bad stuff. If you don’t want html then make sure you encode it into the appropriate entities, watch for header injection in email forms and in general watch for things that could do malicious things like scripts.
For some limited security you could restrict form posting to your domain. You can do this by inspecting the Host HTTP header. Keep in mind that there are various ways to get around this so it shouldn’t be used as a last line of defense. It is however a pretty “low cost” operating in most web scripting languages so why not?
If you are writing mail forms:
Don’t trust the client. The worst thing you can do is cram all of your email info into hidden fields on the form. Think how hard it is for the average cracker/script kiddie to just save the source of your form and change a few lines to turn your form mail script into a spam engine.
And finally rate limit submissions to prevent devious users from setting up a bot that spams the heck out of the person who receives emails from the form. Probably the easiest way to do this is track the IP address in a scoreboard file (or database table) and disallow the IP to send any more emails if they submit the form x times a minute.
You could do other things if you have the time, knowledge and desire but at the very least you should validate your data on the server side in addition to the client side. If you do not, as surely as the sun does rise the script kiddies and crackers will find you.
Outside of input validation at all tiers, my biggest security pet peeve for apps is when people use easy to script url parameters, such as “MLSNum=84145″. 84146, 84147… the fun never ends until the data is scraped. Just use a GUID, for goodness sake!
Matt Cohen said this on September 21st, 2006 at 10:09 am