tags:

views:

95

answers:

5

Hey Everyone,

On the PDO::Prepare page it states,

"and helps to prevent SQL injection attacks by eliminating the need to manually quote the parameters"

Knowing this, is there a PHP function like mysql_real_escape_string() that takes care of escaping stings for PDO? Or does PDO take care of all escaping for me?

EDIT

I realize now that I asked the wrong question. My question really was, "What all does PDO take care of for me?" Which I realize now with these answers that it really only removes the need to escape the quotes. But I would still need to do any other PHP sanitize calls on the values that I pass to the execute function. Such as htmlentities(), strip_tags()...etc...Thanks for all of the help on this!

Thanks for any help!
Metropolis

+1  A: 

You don't have to worry about it. PDO does not require you to escape your data before passing it along to the database.

Edit: Just to be clear, I mean to say that as long as you are passing variables into your parameters (for example, the value of a form field), you don't have to worry about it. However, if you're passing variables that you've defined as strings, for example, then obviously you need to escape anything that needs escaping in that string in order to avoid breaking syntax. However, this wouldn't even make much sense since one of the main advantages of PDO is that you're passing information from the user to the database without having to sanitize it yourself, and there aren't many times (if any?) that you would be passing strings that you yourself had defined.

Also, make sure you still sanitize your data for type. For example, make sure it's an integer if you expect it to be, make sure it's less than or greater than x if you expect it to be, etc.

Josh Leitzel
Ok cool....so all special characters should be taken care of? Like HTML tags, quotes...etc..
Metropolis
Assuming that you're binding your parameters to the prepared statement, yes. (Obviously if you're writing the text yourself in PHP code, for example into a variable, then it needs to be escaped so as not to disrupt the syntax.)
Josh Leitzel
@Metropolis html tags has nothing to do with SQL at all, and quotes doesn't matter for the binding, as there are no delimiting surrounding quotes - so, nothing to escape.
Col. Shrapnel
Sorry OP, in case I wasn't clear enough I've edited my post.
Josh Leitzel
@Metropolis escaping to prevent SQL injection has nothing to do with html tags etc. You still need to escape stored input when you output it to a webpage if it contains html you don't want parsing etc.
@Col. Shrapnel my question about the HTML was asked because I was wondering if htmlentites needed to be used on the values that I am passing in to replace the (?)'s in the statements.
Metropolis
@MrXexxed I know that escaping to prevent SQL injection has nothing to do with html tags. My question was, what exactly does PDO take care of for me? Maybe I need to reword this.
Metropolis
@Metropolis the answer remains the same. it is **html** entities function, not **SQL** entities function. there are a whole lot of escaping functions in PHP - escapeshallcmd(), preg_quote(), etc. **You don't have to use them all** but only ones which applicable for the every particular case.
Col. Shrapnel
+3  A: 

Yes and no:

  • Literals which you embed into the statement string need to be escaped as normal.
  • Values which you bind to the prepared statement are handled by the library.
tc.
Right, that makes sense
Metropolis
+2  A: 

If you prepare a statement and use bindParam or bindValue to supply variables, you do not need to escape the variables. Note that these functions assume that the variable contains a string, so use the third parameter to bindValue if you want to use booleans or floats.

Sjoerd
Im using prepare, and execute.....I do not use the bindParam, or bindValue functions.
Metropolis
@Metropolis: That's fine. If you pass the question mark ? or :named parameters as arguments to ->execute(), it has the same effect as bindParam. Just take care that these should reference text columns then.
mario
+5  A: 

PDO does not escape the variables. The variables and the SQL command are transferred independently over the MySQL connection. And the SQL tokenizer (parser) never looks at the values. Values are just copied verbatim into the database storage without the possibility of ever causing any harm. That's why there is no need to marshall the data with prepared statements.

Note that this is mostly a speed advantage. With mysql_real_escape_string() you first marshall your variables in PHP, then send an inefficient SQL command to the server, which has to costly segregate the actual SQL command from the values again. That's why it's often said that the security advantage is only implicit, not the primary reason for using PDO.

If you concat the SQL command and don't actually use prepared statments (not good!), then yes, there still is an escape function for PDO: $pdo->quote($string)

mario
Actually this is incorrect. Both pdo and adodb use `mysql_real_escape_string()` when connected to mysql. I've looked though the code.
Rook
@The PDO is not the same as ancient ADODB. And you have seen wrong code :)
Col. Shrapnel
@Col. Shrapnel pdo is written in c++ and adodb is written in php. They both use mysql_real_escape_string() (which is apart of the offical mysql client library). You have to escape input at some point, there is no other way.
Rook
@The `You have to escape input at some point, there is no other way.` lol you just don't understand the way native binding works. it IS that other way. May be some ancient PDO version used escaping. But not nowadays.
Col. Shrapnel
mario
+1  A: 

Very few people here understands what escaping is and when to use it.
Escaping itself do not make any data "safe". it just escape delimiters, to distinguish a delimiter from a part of data. field = 'it's me' will cause an error, while field = 'it\'s me' will not. That's the only purpose of escaping. So, it works only when you use quotes. If you don't - escaping become useless.

Do you use quotes with placeholders? No. Thus, no escaping would be sensible.

When you use binding, it works very different way.
It does not send the whole query to the server, but send your prepared query separate from the binded data. So it cannot interfere. And thus no injection possible.

Col. Shrapnel