Is addslashes() the same as mysql_escape_string() in php?

Addslashes only escapes quotes by putting a slash before them. You shouldn't use this with SQL because you need to use stripslashes on the data when you retrieve it.. and in some rare cases, where the data may already have escaped characters, you end up with extra slashes that can be hard to get rid of.

mysql_real_escape_string (which you should be using) only escapes characters which would cause mysql a problem.

That's only a very basic/mediocre explanation, but it's the gist of it.

Addslashes only escapes quotes by putting a slash before them. You shouldn't use this with SQL because you need to use stripslashes on the data when you retrieve it.. and in some rare cases, where the data may already have escaped characters, you end up with extra slashes that can be hard to get rid of.

mysql_real_escape_string (which you should be using) only escapes characters which would cause mysql a problem.

That's only a very basic/mediocre explanation, but it's the gist of it.
yeap but it still puting \ before quotes :) and it do goes to the database...

Dan L provided a good answer about the difference between the functions.

But IMHO, you shouldn't be using either. What you need to be using is PDO (http://www.php.net/pdo) and prepared statements (http://us.php.net/manual/en/function.PDO-prepare.php) with placeholders. It is the absolute most secure way to make SQL queries, and you don't have to deal with escaping quotes of any of that other nonsense.

It would look something like this:

// Prepare SQL statement
$sqlStatement = $this->db->prepare("
SELECT *
FROM customers
WHERE customer_id = :customer_id
ORDER BY lastname ASC
");
$execute = $sqlStatement->execute(array('customer_id' => (int) $customerId));

// Check result
if($execute) {
$result = $sqlStatement->fetchAll(PDO::FETCH_OBJ);
} else {
$result = false;
}

PDO doesn't add any more security than mysql_real_escape_string .. i'm sure it in fact uses mysql_real_escape_string under the hood.

mysql_real_escape_string also handles any special needs if you are using different character sets and whatnot. It's the way to go.

Don't always just reply on escape string functions and do additional checks with regular expressions to ensure the data passes security/sanity checks as well.

PDO doesn't add any more security than mysql_real_escape_string .. i'm sure it in fact uses mysql_real_escape_string under the hood.

mysql_real_escape_string also handles any special needs if you are using different character sets and whatnot. It's the way to go.

That is absolutely wrong. I suggest you do more research on prepared statements with named placeholders or at the very least read up on PDO at the PHP website with the link I provided before making a comment like that. A prepared statement will send the query to the database ahead of time so it can map it out and optimize it's performance by compiling the query and creating a 'query plan'. When you call the execute function later, it then sends only the values to the database, which are inserted into the placeholders of the query you sent earlier by the database engine itself.

Here's a direct quote from the PHP manual on the PDO page (http://us3.php.net/pdo): (emphasis added)

Prepared statements and stored procedures

Many of the more mature databases support the concept of prepared statements. What are they? You can think of them as a kind of compiled template for the SQL that you want to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

* The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize it's plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down your application if you need to repeat the same query many times with different parameters. By using a prepared statement you avoid repeating the analyze/compile/optimize cycle. In short, prepared statements use fewer resources and thus run faster.
* The parameters to prepared statements don't need to be quoted; the driver handles it for you. If your application exclusively uses prepared statements, you can be sure that no SQL injection will occur. (However, if you're still building up other parts of the query based on untrusted input, you're still at risk).

Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that you will be able to use the same data access paradigm regardless of the capabilities of the database.


Meaning that if you always use prepared statements with placeholders in every part of your query, you're safe from SQL-injection attacks.

And another gem from the PDO::prepare() (http://us3.php.net/manual/en/function.PDO-prepare.php) function page: (emphasis added)

Calling PDO->prepare() and PDOStatement->execute() for statements that will be issued multiple times with different parameter values optimizes the performance of your application by allowing the driver to negotiate client and/or server side caching of the query plan and meta information, and helps to prevent SQL injection attacks by eliminating the need to manually quote the parameters.

Exerpt from the php documentation for mysql_real_escape_string


Using mysql_real_escape_string() around each variable prevents SQL Injection. This example demonstrates the "best practice" method for querying a database, independent of the Magic Quotes setting.


Given that this is a wrapper for the C call given to us by the people who wrote mysql, I think its probably pretty safe.

Don't get me wrong, PDO is fine as well, it's just not magically more secure than proper string escaping. I'll correct my self and state that it isn't using mysql_real_escape_string under the hood, and so if you are doing large inserts it's likely going to be faster since it looks like it just sends the raw data to the server instead of building up strings, sending the strings to mysql, and letting mysql parse them back out again, however mysql_real_escape_string will indeed be just as secure.

PDO is fine... but mysql_query is simpler to get going, clearer in code, and just as secure if used in conjunction with mysql_real_escape_string, so take your pick.

Is addslashes() the same as mysql_escape_string() in php?

A small point, but I believe you also need an existing connection to mysql before you can call mysql_real_escape_string().