Cleaning form input data - please help

[peppino]

Im looking for a function that will clean user submitted form data.

I've looked all around the web for a good function that will do this, but all the ones i have found are really super simple or super complex.

i just want a basic function that will clean the input and help reduce risk or causing errors while inputting the data into the database and also removing html tags, code, and other things that can cause problems.

Does anyone use something similar in their own code? If so could you please paste your function and maybe a simple explanation of what it does.

I am really just not sure what things are the most important things that need to be cleaned out from the form input.

Im still a novice at PHP and your help is MUCH appreciated!

[sneakyimp]

user input validation comes in every shade from black to white. general rules that i live by:

1) never rely on vars defined by register_global settings. I refer directly to $_POST['varname']
2) i remove any magic_quotes which may have automatically been applied by the server while I'm inspecting and validating the data.
3) I validate the heck out of the data for the specific thing i'm working on. If i'm expecting a date, I don't let users enter 'foobar'.
4) VERY IMPORTANT: If user input is going into a query, i do one of the following for each and every data point
use the user input to select an acceptable value from a list i define in my code
verify that numeric data is in fact a number using is_numeric()
* escape any text input by using mysql_escape_string() or mysql_real_escape_string
only AFTER i have done all that will i put any user input into a query.

Beyond that, everything depends on your specific application. There is no such thing as a catchall input validator.

[MarkR]

You can't make a generic function to do this and just slap it in an include, because each form's field validation will have different rules.

Personally I do check for silly things globally, but they're not that important. You should validate stuff on a case-by-case basis.

For integers, I normally don't bother checking that it's an int, instead just cast it using

$id = (int)  $_POST['whatever'];

For example. This means that $id will become 0 if it's not a valid integer, which means it will probably fail later on as 0 is never a valid ID in my databases.

Mark

[peppino]

Awesome thanks for all the tips and tricks!

[void_function]

As said above, for integers (or floats) simply typecast into int (or float) without thinking.

For strings, you have two types of attacks that you need to solve for:

1. SQL injection - this is accomplished by smart pre-escaping of your escaping of slashes. Addslashes() has proven weak. mysql_real_scape_string() is much stronger, as any engine-native escape function, but I hear it can be pre-escaped in some cases. Strongest form against SQL injection that I know is using mysqli and prepared statements, if you have access to PHP5 and Mysq4.1+.

2. XSS attacks (cross site scripting) - this is accomplished by injecting malicious html or scripting code into content that will be SHOWN BACK to users, especially admins. By injecting a script that collects cookies and passes through an IMG link to attacker's server, they can hijack sessions. Or they can change content of the website, generally they can do wahtever they want with (presented) content. So basically, strip tags like <script> <applet> <object> <embed> <iframe>. Also watch for urlencoded "<" and ">" chars. If you use utf-8 or any other two-byte encoding, make sure you have consistent encoding in html, database collation and wherever string manipulation is required (like escaping with slashes)

CSRF (cross site request forgeries) is biggest problem, but not solvable with input cleaning. It exploits GET protocol by forging authentication. By injecting a harmless image tage in a forum post, for example: <img src="admin.php?action=delete_content&content_id=123">, even with bbcode, your browser contacts admin.php with given GET parameters thinking it evokes an image. Admin.php will likely check session or other cookies for authentication - which are available if you're logged in as admin - and will proceed deleting the content. This is just a stretched example, but this is how CSRF works.

As for register_globals, always have that turned off.

Very good protection:

1. Check input by Javascript (and dissallow form submission if invalid)
   1a. Make sure form can't be sent by accident if Javascript is disabled (change action by javascript)
2. Re-check input on server-side
3. If invalid, means Javascript avoided, means hacking attack, ban IP automatically or do something else to protect self

I suggest reading this and the links to articles presented within:

http://www.whitehatsec.com/presentations/phishing_superbait.pdf