Keep in mind sanitizing like this may breakyour web application. (Most likely visually at some points.)
1. You can search and replace $_GET['something'] with htmlentities($_GET['something'], ENT_QUOTES). (Do NOT forget to put the ENT_QUOTES flag. This also goes for htmlspecialchars().)
If you need to do this across many GET or POST variables, etc., use a regular expression where the contents of $_GET['X'] is matched like [a-zA-Z0-9], along with the linux scripting it can work.
The second alternative may also break the web application, and I'm not sure this is possible, but try this for starters and for fun:
$_GET = htmlentities($_GET, ENT_QUOTES)
You may have to call all of the arrays at once or do a "for each" in the $_GET array, and then redefine it, but that may also work.
Just keep in mind, that if some of your web apps needs unsanitized characters it's game over.
Also, when it comes to SQL Injection, htmlentities() and htmlspecialchars() can actually prevent some types of injections, but generally you should either use mysql_real_escape_string() or prepared statements.
Keep in mind, that with at least mysq_real_escape_string() or your own custom function (which I can't recommend you create as custom sanitization functions often has bugs), can still be vulnerable if implemented incorrectly.
"SELECT id FROM users WHERE id = ". mysql_real_escape_string($_GET['id']). "; is vulnerable to SQL Injection, as you can do blind injections like 1 OR 1=1. Same if you use htmlentities or htmlspecialchars in this case. Therefore, make sure you use encapsulation the right places, and if you're using integers for input, make SURE you do it right like:
"SELECT id FROM users WHERE id = ". intval($_GET['id']) ."; (Keep in mind this is a signed integer, if you need larger numbers than what a 32-bit system can produce, use something like floatval() instead.
This eliminates strings in user-input where you only want numbers. You can of course add regular expressions for your input, as long as you do NOT use the 'e' (evaluate as PHP) flag, as that can be quite dangerous to use, especially along with variables like this "$var" as that is evaluated too, compared to '$var'.
If you have identified all vulnerabilities with a web scanner and you're 99,9% sure of this, work your way from there and fix the vulnerabilities manually.
Instead of using scripts like this: echo "Your name is: ". $_GET['name'];
Do it like this:
$name = $_GET['name'];
echo "Your name is: ". $name;
Then re-use the $name variable wherever you need it, and if you need to change the sanitization it uses, you can just change definition of the $name = $_GET['name']; variable to e.g., $name = htmlentities($_GET['name']);
Now, all of this is nice, but what about:
- Session management (are sessions and cookies secure (not easy to predict or steal) and being handled correct?)
- Anti-CSRF tokens (If they don't exist, these needs to be added to forms. If there's a million forms, begin with those that relates to any administrative function (especially change password functions), and then work your way to normal user functions, then unprivileged functions even though the last one is not as important as the first two.
Take a look in the web application hacker's handbook vol. 2 in case you haven't.
I should note, that Owasp actually does have an input sanitizer application available, but you should be careful putting all your trust in one application. Do you trust your firewall 100%? I don't trust mine, as I know it can be bypassed like any other firewall.
My 2 cents for today