Some good common sense here, and well written too.

I felt a little insulted reading this. Surely everyone who reads this knows about all this?

Then there's the little pang of guilt, because I know of one or two apps finished in haste, in which I have made one or more of these mistakes. I've been meaning to fix that, but there's just never enough time.

So.. maybe not so trivial after all... But if you're looking for a way to tighten security on your web apps, these aren't exactly the most common or the most likely flaws (at least as far as I've seen).

The input limiting rule here is sound security practice, but it could make life very hard if you ever need to internationalise your application.

> "the best way to check is to do a direct comparison with the value that you just set in the web page. Of course, if you can do this, there's really no point in having the hidden fields at all"

No, no, no, no. There is still all the point in the world in having hidden fields, and they should contain a randomly-generated pseudo-session-id that you must validate (as you say, by direct comparison - you're right about not just blindly trusting the content) before accepting any requests. That's how you prevent CSRF, remember?

See, for example, the following ElReg article from August this year by one "Jeff Williams"...

http://www.theregister.co.uk/2008/08/29/hijacked_browser/

... A slight attack of amnesia, perhaps?

Of course, data acquired from HTTP GET or HTTP POST must be validated ... but most of the ugly stuff (like O'Malley, or '; DELETE FROM users; --) is usually covered by PreparedStatements, which are supported by any RDBMS worth its salt. Any programmer *not* using these is opening a big SQL Injection vector into his app.

I wish every single developer knew about this, but I've seen companies using queries that don't do any kind of sanity check on these things; and generating documents with things like:

http://foobar.com/servlet/VeryImportantContractGenerator?name=Jason%20Bourne&account_no=1234432198&initial_balance=300

which, of course, doesn't validate the input at all. These kind of things make me cringe...

If those unvalidated query parameters make you cringe, try googling "allinurl: select from where" some day...