Denial, exposure and online security

Web applications have huge attack surfaces. Most sites have hundreds of URLs, and each function has plenty of parameters, form fields, cookies, and headers for attackers to play with. One simple way to make your web application more secure is to minimize your attack surface. Let's look at five simple ways to do this. Tighten …

[Moss Icely Spaceport]

Interesting

Some good common sense here, and well written too.

[Anonymous Coward]

Web security 101

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).

[breakfast]

Good input

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

[Anonymous Coward]

Ditch those hidden fields - WRONG!

> "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?

[Daniel B.]

PreparedStatements

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...

[Anonymous Coward]

@Daniel

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