I can understand the reason behind sanitizing inputs, but what is the risk of not escaping output, particularly output that is coming straight from our database?
If the data is sanitized going in, how is it exploited on the way back out?
Not all data from your database will be safe. Most of it will be content written by your users. They might, for example, write script tags in their content that could steal information from other users. If you’re escaping HTML before inserting into the database, then the good news is you are indeed protected from those kind of tricks. Though, it’s generally considered better to escape on the fly while rendering your templates, not before inserting into the database. HTML may be the most common output format, but you might also need to output user content to JSON format for an ajax request, or to plain text for an email or external web service. In short, user content isn’t always destined for HTML, so it’s best not to hard-code HTML formatting into the database.
One of the best ways to remember why you need to properly escape data going to a dbase is to recall the story of little bobby tables.
If you don’t understand it, come back and ask.
i don’t understand how that example explains why you have to sanitize database information on output
Oh dear. I didn’t read the question properly did I?
The fundamentals of escaping the output remain though, you have to escape data in readiness for the environment which will be the next destination.
So, in my (mistaken) reply, PHP data is received in one hand (where it should be Filtered against expectations) and in the other hand then escaped for the SQL environment. The point is to avoid leaving yourself open to a bobby table type SQL-injection attack.
Now, when taking stuff out of a database for display, say, on a webpage (again pretty much the PHP web scenario) then it is incumbent on us to protect other users (ie viewers of your webpage) from XSS attacks, whereupon bad things can be injected as say JS calls in a html attribute.
PHP has inbuilt functions to accomplish this. (htmlentities() and so on).
The use case might be this:
$incoming = “Some text I entered into your blog comments <script onload=alert(cookie)></script>”;
While that can be escaped and put safely into your database, when you get it out and display it – it can have consequences for viewers of your webpage. That cookie value can just as easily be sent to another website.
You might escape values differently if it was going to a pdf file, a csv file, or on to your mail() handler.
The rule is FIEO (Filter Input Escape Output).
The OP mentions sanitizing the incoming data and asks why it needs to be escaped again, well if you are dealing with a phone number and that matches a known format and you enforce that format, then arguably you do not need to escape it when you display it. If it is a free-form text input as you experience in blog comments then it is almost impossible to successfully sanitize the data.
This site scarily demonstrates the range of methods which are open for attackers to use in order to create, say, a <script> tag in any form element you have on your page. (they could also send it in via a cookie).
So, at the sharp end of your output can you be sure that the var $row[‘tel_no’] does not need escaping and that you are pretty sure that $row[‘comment’] does?
Or should you fall back to escape everything in principle just in case you, or some other coder did not Filter and perhaps sanitize the data in this particular case?
Some other reading here [google]protect XSS attack php[/google], PHP is not alone is having to protect users from XSS attacks and CSRF attacks etc.
I trust this makes up for my over-eager and misconstrued reply 
Sorry all.
Edit: Whoops CUPS snuck in first; same idea
The term FIEO (filter input, escape output) is commonly thought of in securing PHP applications. The main idea is that both input and output data can never be interpreted as anything other than data, so not not affect an application’s functionality. Escaping output protects against XSS vector attacks. As @Jeff Mott suggests, a user might store a javascript string to be used as an attack when printed to the screen, by not trusting that our output data is clean you can better protect your application. After all you don’t know at any given time if a PHP session has been compromised, a hacker has spoofed your input form and bypassed all your form validation or it has bad data has been placed in your database.
Regards,
Steve
Thank you all for the informative replies. I think this pretty much confirmed what I believed, if I’m understanding correctly, which is to escape your output just in case your input filter may’ve missed something.
So if I
SELECT * FROM mytable
then put the information into variables like
$field01=mysql_result($result,$i,“first_name”);
do I then clean the data with
$field01=(htmlentities($field01)?
Will that mostly keep the site safe (in this specific case)?