Sanitizing User's Data in Get by PHP

Sanitizing user's data in GET by PHP

How do you sanitize data in $_GET -variables by PHP?

You do not sanitize data in $_GET. This is a common approach in PHP scripts, but it's completely wrong*.

All your variables should stay in plain text form until the point when you embed them in another type of string. There is no one form of escaping or ‘sanitization’ that can cover all possible types of string you might be embedding your values into.

So if you're embedding a string into an SQL query, you need to escape it on the way out:

$sql= "SELECT * FROM accounts WHERE username='".pg_escape_string($_GET['username'])."'";

And if you're spitting the string out into HTML, you need to escape it then:

Cannot log in as <?php echo(htmlspecialchars($_GET['username'], ENT_QUOTES)) ?>.

If you did both of these escaping steps on the $_GET array at the start, as recommended by people who don't know what they're doing:

$_GET['username']= htmlspecialchars(pg_escape_string($_GET['username']));

Then when you had a ‘&’ in your username, it would mysteriously turn into ‘&’ in your database, and if you had an apostrophe in your username, it would turn into two apostrophes on the page. Then when you have a form with these characters in it is easy to end up double-escaping things when they're edited, which is why so many bad PHP CMSs end up with broken article titles like “New books from O\\\\\\\\\\\\\\\\\\\'Reilly”.

Naturally, remembering to pg_escape_string or mysql_real_escape_string, and htmlspecialchars every time you send a variable out is a bit tedious, which is why everyone wants to do it (incorrectly) in one place at the start of the script. For HTML output, you can at least save some typing by defining a function with a short name that does echo(htmlspecialchars(...)).

For SQL, you're better off using parameterised queries. For Postgres there's pg_query_params. Or indeed, prepared statements as you mentioned (though I personally find them less managable). Either way, you can then forget about ‘sanitizing’ or escaping for SQL, but you must still escape if you embed in other types of string including HTML.

strip_tags() is not a good way of treating input for HTML display. In the past it has had security problems, as browser parsers are actually much more complicated in their interpretation of what a tag can be than you might think. htmlspecialchars() is almost always the right thing to use instead, so that if someone types a less-than sign they'll actually get a literal less-than sign and not find half their text mysteriously vanishing.

(*: as a general approach to solving injection problems, anyway. Naturally there are domain-specific checks it is worth doing on particular fields, and there are useful cleanup tasks you can do like removing all control characters from submitted values. But this is not what most PHP coders mean by sanitization.)

How can I sanitize user input with PHP?

It's a common misconception that user input can be filtered. PHP even has a (now deprecated) "feature", called magic-quotes, that builds on this idea. It's nonsense. Forget about filtering (or cleaning, or whatever people call it).

What you should do, to avoid problems, is quite simple: whenever you embed a a piece of data within a foreign code, you must treat it according to the formatting rules of that code. But you must understand that such rules could be too complicated to try to follow them all manually. For example, in SQL, rules for strings, numbers and identifiers are all different. For your convenience, in most cases there is a dedicated tool for such an embedding. For example, when you need to use a PHP variable in the SQL query, you have to use a prepared statement, that will take care of all the proper formatting/treatment.

Another example is HTML: If you embed strings within HTML markup, you must escape it with htmlspecialchars. This means that every single echo or print statement should use htmlspecialchars.

A third example could be shell commands: If you are going to embed strings (such as arguments) to external commands, and call them with exec, then you must use escapeshellcmd and escapeshellarg.

Also, a very compelling example is JSON. The rules are so numerous and complicated that you would never be able to follow them all manually. That's why you should never ever create a JSON string manually, but always use a dedicated function, json_encode() that will correctly format every bit of data.

And so on and so forth ...

The only case where you need to actively filter data, is if you're accepting preformatted input. For example, if you let your users post HTML markup, that you plan to display on the site. However, you should be wise to avoid this at all cost, since no matter how well you filter it, it will always be a potential security hole.

Sanitize User Input via PHP

This function you just posted has nothing with "random files appearing" in your directories. these are for string sanitizations and you aren't sanitizing integers either. If you use this function to sanitize your database inputs then you must validate the data you're entering first so it matches your needs, so if you expect an integer, you make sure its an integer and not just add slashes to it to stop the quotes in strings, if you expect a string you make sure it's a string. If you plan on displaying any data inputted by the user then you must protect against XSS. If your server has vulnerabilities then the problem is not with your website but with the software installed on the server itself. as for the randomly appearing files, the only way I can think of is if you allowed some users to upload pictures or files without making sure what their extension is and therefore allowing people to upload PHP files or HTML codes. Finally, I'd just like to clear that NO ONE can give you a sanitization function that will match your needs, you need to make one for your exact needs because no one but you knows what type of data you're expecting.

This is a general rule in protecting your website against any user input whether it was a file uploaded or a user being registered

1. Validate the data and make sure it's the type of data you're expecting.
2. Sanitize that data so that it cannot contain any malicious codes that may compromise your website.

Sanitizing data before storing it might mean stored data is different to what the user entered - is that common practice?

Best practice seems to be to sanitize the data before sending it to the database.

This is a common misconception. Sanitization should only be performed on data that is being output, to prevent XSS for example and even then only as a last resort. Exactly because it can irreversibly destroy the original data.

Validation is your first line of defense. Make sure that the data is properly formatted, and valid within its context - just that; no looking for special characters, don't be over-zealous. If it's not valid - reject it, don't try to salvage the "good" parts from it.

Then, when storing in database, you merely need to use parameterized queries - that is 100% effective against SQL injections. If you didn't mangle the data in a previous step, you're storing it in its original form.

And finally, when the data is being output, that is where you SHOULD escape special characters within the appropriate context, so that it is properly rendered; or sanitize it if you have no other choice (i.e. the context is unclear and therefore you can't do proper escaping).

Sanitize html inputs with php

The validation depending mainly on the context of your website, what's should be confirmed to keep database consistent as possible.
Also there are some validations which are like a global or public, such as trim() and stripslashes()

The main function of validation is to check user inputs that will stored in database and used in future, such as email or phone number and password of user when login or sign-up.
You should validate that phone number is numeric and only 12 length. Or validate that email is in correct format.

About what to use for validation, you can search about:
FILTERs here https://www.w3schools.com/php/php_filter.asp ,

REGULAR EXPERSSIONS here https://www.w3schools.com/php/php_regex.asp

Other way is by using string functions: here https://www.w3schools.com/php/php_ref_string.asp

Do I need to sanitize user data for error_log() in PHP?

If you want to play it safe:

error_log(addcslashes($message, "\000..\037\177..\377\\"));

that will encode all non-printable and non-ASCII characters (i.e. any byte that wouldn't match /[\x20-\x7E]/) and double any original backslash

PHP and MySQL - Should I validate/sanitize my data when pulling it from my database before displaying to user?

Input validation should be a yes/no proposition. You should not modify input and save it.

You should use Htmlentities after pulling from the DB and before showing. This is because it's better to clean data just before using it at the point of failure. This is why prepared statements work so well, because there is no external code you rely on.

Say you forget to sanitize 1 field in 1 form, then when you ouput that data to other users you have no way to see that mistake from the code that does the output (assuming its not in the same file).

The less code between the sanitizing and the end result is better.

Now that is not to say save everything and validate it later. Take an email for example, you should validate that for the proper format before saving.

But for other things you don't want to modify user input. Take a file upload. Some people will change the filename to sanitize it, replace spaces etc. This is good but I prefer to create my own filename, and then show them the origainal file name, while the one I use on the server is a hash of their username and the name of the file. They never know this, and I get clean filenames.

You start modifying user data, and it becomes a chore to maintain it. You may have to un-modify it so they can make edits to it... etc. Which means you are then doing way more work then if you just clean it when outputting it.

Take for example the simple act of replacing a users \n line returns with a <br> tag. User inputs into a text field then you change it to html and save it. (besides security reasons not to do this) when user wants to edit the data, you would have to take the <br> and replace them with \n so they can edit it. Security reasons being now you have decided that raw HTML in that field is ok and will just output the raw field, allowing someone a possibility to add their own HTML. So by modifying user data we have created more work for yourself, and we have made assumptions that the data is clean before inserting it when we output it. And we cannot see how it was cleaned when we output it.

So the answer is it depends on the data and what sanitation you are doing.

Hope that makes sense.

Sanitizing data PHP - do i need to escape user inputs that are inside if statements?

The only reason you ever need to escape something is when you're interpolating data into another text medium which gets re-interpreted according to some rules.

E.g.:

echo '<p>' . $somedata . '</p>';

This is programmatically generating HTML which will get interpreted by an HTML parser and will have specific behaviour depending on what's inside $somedata.

$query = 'SELECT foo FROM bar WHERE baz = ' . $somedata;

This is programmatically generating an SQL query which will get interpreted by an SQL parser and will have specific behaviour depending on what's inside $somedata.

If you want to ensure that HTML or that query behaves as you intended, you better make sure you generate those textual commands in a way does that not allow anyone to inject unwanted commands.

if ($somedata == 'something')

Here you're not creating some new text which will be interpreted by something. There's no way for anyone to inject anything here. It's not like PHP is replacing $somedata with the contents of $somedata and then re-interprets that line with the interpolated data. So there's no need to escape this in any way.

Also see The Great Escapism (Or: What You Need To Know To Work With Text Within Text).

---

Related Topics