SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    40
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Post Sessions + mysql_real_escape_string

    Hello,

    If I am grabbing a post value, I would do something like this to make sure it is safe for a database query and to avoid SQL injection attack:

    Code PHP:
    $email= trim(mysql_real_escape_string($_POST['email_field']));

    I know people can mess with sessions and I was wondering if you need to do the same thing for them?

    Code PHP:
    $username= trim(mysql_real_escape_string($_SESSION['username']));

    or is it safe to just have:
    Code PHP:
    $username= $_SESSION['username'];

    Thanks

  2. #2
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Only you can change sessions (unless someone gets access to the session files).

    If your usernames have special characters, then you need to do it. If they don't, you don't have to. However, it doesn't hurt to do it and if you ever allow special characters in usernames, you won't have to change your code.

  3. #3
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,810
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    You should validate all fields to make sure that what they contain is meaningful for the field and not just rely on mysql_real_escape-string unless the field is validly allowed to contain anything at all.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  4. #4
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    mysql_real_escape_string is not a security measure; It's a way to ensure that data gets interpreted correctly. As a side effect, wrongly encoded data may cause holes, which can be used as attack vectors. But even if not, it's fundamentally wrong to *not* escape strings, when you embed them in SQL. So to summarise; You must escape each and every string that you use in a query, no matter the source of it.

  5. #5
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    mysql_real_escape_string is not a security measure; It's a way to ensure that data gets interpreted correctly. As a side effect, wrongly encoded data may cause holes, which can be used as attack vectors. But even if not, it's fundamentally wrong to *not* escape strings, when you embed them in SQL. So to summarise; You must escape each and every string that you use in a query, no matter the source of it.
    Even when using PDO prepared statements?

  6. #6
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    data used to fill in the placeholder values in prepared statements doesn't need to be escaped.

  7. #7
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by risoknop View Post
    Even when using PDO prepared statements?
    No, because when you're using bound parameters (prepared statements), you are never mixing SQL and data. That's the brilliant thing about them. In fact, if the database driver supports it, with bound parameters, the SQL and the data are sent separately, so it is impossible to get any kind of buffer overflow type errors, making them even more secure than escaped strings. So by all means - use bound parameters, if possible, and then forget all about escaping (for SQL at least).


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
  •