dcsimg
www.webdeveloper.com
Results 1 to 2 of 2

Thread: Why do we sanitize besides preventing injection?

  1. #1
    Join Date
    Dec 2006
    Posts
    48

    Why do we sanitize besides preventing injection?

    Hey everyone, today is a sad day for my php ego.

    I had built this awesome sanitizing thing that would get data from $_GET or $_POST, strip tags, replace any outrageous characters with an underscore, and then replace anything left (besides letters, numbers, and spaces) with a left brace, ascii code, then right brace. So:
    ¿my name's Khelavaster?
    ...would become:
    _my name{39}s Khelavaster{63}

    Which is safe for inserting into a database. And then when I eventually display it again, I can decode it back to: "_my name's Khelavaster?"

    I thought it was pretty cool.

    But now I hear about this newfangled contraption called mysqli! It makes it so I don't have to worry about SQL injections? But that's the only reason I made my sanitizing thing!

    So I need to know if there's any other reason to sanitize user input than preventing SQL injections. If there isn't, then I'll move on, delete my sanitizing code, and use mysqli like god apparently intended. If there is, then I'll keep my sanitizing scheme and use mysqli too.

    The question is, why do we sanitize user input if mysqli takes care of preventing SQL injections for us?

    (Also, criticism on my sanitizing thing is welcome--I know there's better ways to do it out there)

  2. #2
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,616
    As far as the database is concerned, things like HTML tags and special characters are of no concern. The only things of concern are a handful of specific characters that can have a negative effect on your SQL, such as quotes or semi-colons. With the MySQL interface, mysql_real_escape_string() takes care of that issue, and it is therefore the only thing you need to do to prevent SQL injection issues. With MySQLi, you have the same sort of escaping function, or you can instead use bound input parameters in conjunction with prepared statements (which then does the same sort of escaping automatically where needed).

    Things like strip_tags(), htmlentities(), not allowing certain characters, etc. has nothing to do with SQL injection. They have to do with any validation you want to do with regards to what sort of data you want to allow the user to enter, or with filtering and/or escaping of output from the application to the client (browser).

    I therefore recommend keeping such validation/filtering/escaping issues separate from the specific escaping done to prevent SQL injection, since if you combine them then you are combining the application's business logic needs with the separate database interface needs, and you may not always want them linked arm-in-arm like that.
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

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



Recent Articles