php5 security - get/post parameters

Question

What is most efficient method to making sure that get/post parameters won't provide any security vulnerability.

I am familior of htmlentities for javascript code injection prevention and addslashes to prevent sql injection.

so.. for now i'm using them both on each get/post parameter.

are there any other functions i can use to prevent these vulnerabilities better or are there any other security issues that i should worry about related to my php code ?

Answer 1

You can use Data Filtering as a data firewall.

http://www.php.net/filter

Answer 2

GET and POST variables are no more dangerous than any other variables. You should handle injection vulnerabilities at the usage point, not at the input point. See my answer here:

What’s the best method for sanitizing user input with PHP?

Answer 3

This is an example of how to use Addslashes Or Mysql_real_escape_string(): http://zacklive.com/addslashes-or-mysql-real-escape-string-stop-sql-injection/906/

Answer 4

GET/POST are public so the main security concern is to not pass sensitive information (i.e. keys and values that give away your directory structure or db schema). Also remember that anyone can manipulate or create their own HTTP requests so be sure to validate data before inserting it into a database. Other than that they don't pose any threats on their own since they have no effects until you do something with them.

Answer 5

htmlentities (or htmlspecialchars) and addslashes (or mysql_real_escape_string or other database-appropriate escaping function; addslashes is invariably the wrong thing) are nothing to do with GET/POST parameters. They are outgoing-escaping functions whose input might come from parameters, but might equally come from somewhere else, such as a static string or a string fetched from the database.

for now i'm using them both on each get/post parameter.

No, that doesn't work. It's a common mistake, and one perpetuated by a lot of the totally dreadful PHP tutorial material out there. Trying to split off the problem of string escaping into one little loop instead of being spread all over the code sounds nice, but string escaping doesn't work like that in reality. You need to apply the right form of escaping, and only the right form of escaping, at each time you put a string inside another string. You cannot do that in advance.

Don't try to ‘sanitise’ or ‘filter’ all the incoming parameters to encode or remove characters like \ or <. This will result in your application filling up with rubbish like \\\\\\\\\\\\\\\\\\\\\\\\\\ and &. Instead, you should only encode them — along with any other varaibles that don't come from GET/POST — at the last minute when spitting them into a different context of text, like htmlspecialchars for HTML or mysql_real_escape_string for MySQL string literals. You are usually better off with parameterised queries though, which avoids the SQL escaping issues.

That's not to say you shouldn't check your incoming data for conformance to your application's requirements. If you've got a field you expect to get an integer for, be sure to intval it before using it. If you've got a plain single-line text string which you don't expect to contain newlines, be sure to filter the \n character from the string, along with all other control characters [\x00-\x1F\x7F]. But these are application requirements, not something you can necessarily run across all your input.

Answer 6

There are already many good answers, as a rule of thumb you should:

• turn off magic_quotes_gpc
• validate get/post parameters
• html encode parameters before display
• use the escape function of the database in queries

This is just the minimum that will prevent the most common vulnerabilities.