incrediBILL - 7:22 pm on Dec 12, 2011 (gmt 0)
incrediBILL, come on. DO you post here, or what? This Quick Reply box on the forum, how long of a string does it accept?
OK, mixing apples and oranges, big input fields need a little different approach. I didn't intend on writing a complete "how-to" guide, just generalized ideas. I was aiming my comments in specific about general input fields, like some sign-up forms and such, people don't protect them, nor the little "search" boxes they put on their sites that directly query the database.
Obviously on a techie forum like WebmasterWorld you can't be that restrictive, but requiring validated membership to post will often solve the problem assuming your member registration at least has some form(s) of Turing tests and email validation involved.
In fact, even I would shut down several of our small non-profit sites rather than doing extensive and EXPENSIVE hole plugging.
There's that old straw man argument that hole plugging is both extensive and expensive.
I have a global routine that I use which, with a simple addition to .htaccess, now pre-appends all page requests site-wide. This code checks all GET and POST variables being passed and evaluates them for certain bad characteristics and will kick the page request if it sees certain types of data attempting to be input.
It's not hard, it's not complicated, it's not expensive nor was it extensive.
One page of PHP code, couple of lines in .htaccess, and my site passes those security check sites battery of tests with flying colors.
Obviously my code does specific filtering at field levels in the actual application itself, but there's a lot of generic testing you can do site-wide without knowing or caring about the fields being submitted and what should be there as you know for sure what bad stuff SHOULDN'T be there and that can be blackbox tested and rejected globally on the cheap and you never miss any potential hole as the entire site has blanket protection.