[RESOLVED] filter input or output

wmhop

I read this in the comments section of an article and was wondering if it's necessary at all to sanitize input:

2) Ability to sanitize input data is nonsense! Nonsense, which leads to false sense of security.

There is no need to sanizite input data (striping tags or adding magic quotes). Why? Input data are not output data! It is important to escape output data, due OUTPUT CONTEXT. Is output context HTML? Ok, use htmlSpecialChars. Is output context SQL command? Ok, escape data with propriety function, for example mysql_real_escape_string. Various databases use their own escape method. There is no universal way.

But never sanitize input data! Input data are used for some processing. Sanitizing input data leads to badly findable security mistakes.

This was in regards to php's filter functions.

Any thoughts? Or any resources that can lead me to a better understanding of when to sanitize data?

laserlight

The user who posted that is right to say that "adding magic quotes" is nonsense, though stripping tags may be useful (but I agree that it is generally not necessary).

The statement that "there is no need to sanizite input data" is misleading because it is a blanket statement that includes escaping input data before using them in a query, yet that is precisely what "escape data with propriety function, for example mysql_real_escape_string" does. Of course, prepared statements arguably do not "sanitize" input data, but the concept is the same.

Other than that, the concept is generally that one should leave input alone, other than doing any necessary escaping to prevent SQL injection. Then, output should be sanitised to prevent malicious scripting attacks (XSS and the like). The reason is that messing around with input in other ways may lead to corruption of the data since it is no longer in the form expected by the user.

wmhop

So are there really just two instances when you'd want to "sanitize" data? 1) Before using in a query and 2) Before writing to the browser.

laserlight

Yes, though I am hesitant to limit it to such specific examples as "before using in a query" and "before writing to the browser".

wmhop

I'm really trying to get my head around the whole question of when. How would you state the instances when sanitizing is necessary.

Basically, I don't want to do it too late (after it's already done damage) or too soon (basically when it's not necessary).

Thanks for your patience.

laserlight

For most cases of what we would use PHP for, you have it right. However, instead of memorising specific instances, you need to understand the fundamental ideas: sanitise when the data may be interpreted.

In the case of an SQL statement, the data may be interpreted as SQL, so you need to ensure that such interpretation is not possible (unless intended, but you have to be very careful with that). In the case of printing to the browser, the data could be interpreted as clientside code, so it should be sanitised.

Using htmlspecialchars() on data used in an SQL query could make a mess out of the data when it is stored in the database. Using mysql_real_escape_string() on data to be sent to clientside could allow for XSS attacks. So, if you understand what is happening, you can also choose the appropriate mechanisms to sanitise the data.

wmhop

Very helpful thanks.

NogDog

I think of sanitizing inputs as making sure you got the correct type and amount of data for each input. If you did not, then there is no sense in proceeding with processing without either throwing an error and requiring the user to resubmit the data, or else manipulating the input to be valid (e.g. stripping spaces or punctuation out of credit card or phone numbers).

Then when outputting data use the type of filtering which is appropriate for that instance of output, whether it be mysql_real_escape_string for a database query or strip_tags() and/or htmlentities() when adding it to your HTML output.

laserlight

I think of sanitizing inputs as making sure you got the correct type and amount of data for each input.

I would rather call that "input validation" since it has less to do with filtering the Bad Stuff and more with making sure that the input conforms to some pattern.

NogDog

Call it whatever you like. 🙂 I guess I would tend to call it "validation" if I reject the data that is...well...invalid, and call it "sanitizing" if I silently manipulate the data, e.g.: casting an ID from the query string to an integer, stripping out all non-digit characters from a cc number, trim()-ing leading/trailing white-space, etc.

PS: I suppose with that definition I might both sanitize and validate a given input. 🙂

halojoy

wmhop wrote:
2) Ability to sanitize input data is nonsense! Nonsense, which leads to false sense of security.
There is no need to sanizite input data (striping tags or adding magic quotes). Why? Input data are not output data! It is important to escape output data, due OUTPUT CONTEXT. Is output context HTML?

This was a visitor comment to the article: PHP Built in Input filtering at http://devzone.zend.com/

In the article the author is using 2 separate words to describe different actions, functions:
Filter and Sanitize.

Action speaks louder than words.
In the end it does not matter what we call it. What terminology we use.
Because many times there is only a very thin line between this and that.
So here I agree with NogDog.

The Author makes clear it is very important to Filter external data.
Which actually is an input.

Don't trust external data

Practically all applications (web, desktop, console) depend on external input to create output or to start an action. This input comes from a user or another application (web services clients, bots, scanner, etc.). The rule #1 of every developer (you all know it, but it does not hurt to write it down once more) should be:
Filter All Foreign Data
Input filtering is one of the cornerstones of any application security, independently of the language or environment. PHP provides a wide range of tools and functions to filter or validate data, but unlike other languages, it does not have any standard functions to filter data (like cgi for perl). The new Filter extension fills this gap.
What's foreign data?
* Anything from a form
* Anything from $_GET, $_POST, $_REQUEST
* Cookies ($_COOKIES)
* Web services data
* Files
* Some server variables (e.g. $_SERVER['SERVER_NAME'])
* Environment variables
* Database query results[/QUOTE]Article Web source: 
http://devzone.zend.com/node/view/id/1113

Regards