2

This is one of things that I really don't get. I know that it's super-important to escape any user sent data. There are lot of methods how to do that: stripslashes() (removes backslashes), strip_tags (removes HTML and PHP tags), htmlSpecialChars (for example, change & to &), regex's (preg_match()) to do not allow process "bad" data.

When to use, how to use, why to use?

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
daGrevis
  • 21,014
  • 37
  • 100
  • 139

4 Answers4

2

If you take the contents of, say, $_POST['album_name'], and out put it directly on your page, then someone could submit HTML and JavaScript, which would then become a part of the page, and now your site is hacked.

Or, you could take the contents of $_POST['album_name'] and put it into an SQL query. But the user has written their own SQL query, which you have now run, and now your database is hacked.

http://xkcd.com/327/

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Matt
  • 3,778
  • 2
  • 28
  • 32
1

This question is very broad. It really depends what you are escaping the data for.

Per example, using stripslashes and strip_tags is good for escaping data to be displayed in a web browser. But it's no good for database queries.

On the other hand, database escaping mechanisms are good when sending user data to a database engine, but they're no good when trying to prevent XSS attacks.

Each escaping function have a specific context where it has to be used.

netcoder
  • 66,435
  • 19
  • 125
  • 142
1

BTW: The best practice to filter user input data in PHP is using filter_input.

Examples:

$userId = filter_input(INPUT_GET, 'user_id', FILTER_SANITIZE_NUMBER_INT);
$username = filter_input(INPUT_GET, 'username', FILTER_SANITIZE_SPECIAL_CHARS);
$email = filter_input(INPUT_POST, 'email', FILTER_SANITIZE_EMAIL);

More filters constants here.

joksnet
  • 2,305
  • 15
  • 18
  • I kind of agree with your idea, but I disagree with the method used. `filter_input` does the same as `filter_var`, but acts on the input stream directly. This makes it difficult to unit test afterwards. Like when [this guy tried](http://stackoverflow.com/questions/4158307/how-to-make-a-phpunit-test-that-depends-on-real-post-get-data) to do it. – netcoder Dec 13 '10 at 15:59
  • PHPUnit test unit cases only. For testing web cases Selenium is a good choice. – joksnet Dec 13 '10 at 17:25
0

If your data is going into the database, you must prevent users from sending data that will escape out of your normal query to break or modify that query. Using MySQLi with parameter binding is the current best way to protect your database. So long as you also use a string or preg replace as well. So that an integer ID is ensured to just be an int. You want to remove as many characters as you logically can from your data.

If your data is going to be placed in-between tags, strip_tags followed by htmlentities is a good practice. However, if you can use a white list, do. If you know the output should only be an int, make sure it is. echo htmlentities(strip_tags($value));

If you are placing that data inside a tag <a href='<?php echo $value; ?>'> the above is not enough. You must also replace single quotes. Here, it is even more vital that you prevent poisoned data from making it in. If $value was something like ' onClick='alert("oops");' you might be in a serious bind. Here you should absolutely use a white list, and only allow user entered content to appear here if you absolutely must.

If you want to output into a JavaScript. Don't. You shouldn't do this even if you've been working with security for years. However. The one exception can be made for VERY specific values. Integers. Strings that are locked to A-Za-z0-9 and space with a preg replace. However. This is VERY dangerous and can seriously compromise your system.

If you want to put variables inside an eval or exec. JUST DON'T. You are not smart enough to prevent an attack. Neither am I. No one is. It is just a matter of time before someone finds a way. And if the code as it was first written was fine? At some later date the code will get changed and won't be fine anymore. Just don't do it. Period. Or one day you'll be sitting in prison wondering to yourself, "But I didn't hack into the pentagon..."

DampeS8N
  • 3,621
  • 17
  • 20