SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Why Escape Database Output?

    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?

  2. #2
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,155
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    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.

  4. #4
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,022
    Mentioned
    53 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Cups View Post
    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
    r937.com | rudy.ca | Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  5. #5
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    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).

    http://ha.ckers.org/xss.html

    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 protect XSS attack php, 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.

  6. #6
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    2 Thread(s)
    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
    ictus==""

  7. #7
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    SitePoint Evangelist
    Join Date
    Apr 2009
    Location
    South Carolina
    Posts
    458
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    PHP has inbuilt functions to accomplish this. (htmlentities() and so on).
    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)?
    Each day is a learning experience.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •