If you're relatively new to the PHP world, you may be wondering why there has been so much emphasis put on "magic quotes" in the language's past. If you're not entirely sure what they are (and why to avoid them) take a look at this quick overview from XpertDeveloper.com.

First of let me say that Magic Quotes is deprected from the PHP 5.3 and will be removed completely from the PHP 6. But as a developer you might face a situation when you have to work on application which runs on older version of PHP with some older functionality like rely on Magic Quotes.

They introduce the simple concept behind the magic quotes idea and, thankfully, the settings and code you can use to turn it off. It's been deprecated in PHP 5.3 but some older versions came with it enabled. If you're currently running with it on, it's highly recommended to turn it off and refactor your code accordingly.

As Michael Kimsal points out, there's a new posting on his brother Mark's blog talking about alternatives to addslashes() in your applications.

I've seen a lot of people talking about mysql_real_escape_string() vs addslashes() vs addcslashes(). There seems to be a lot of real confusion about what these functions do (even with the php.net manual around), especially when it comes to character sets. [...] So, I've decided to lay it all out in a few charts so there is no confusion about what each function does and how each can help protect against SQL injection attacks.

He ran some tests based on what the function does to see if it helps with certain things like "escapes with single quotes instead of backslash" and "prevents multi-byte attacks". He compares the speed and testability of the functions as well as provides a multi-byte breakdown oh how the mysql_real_escape_string function works with different character sets.

Ivo Jansch has a reminder for developers when they're putting user data into their databases - don't use addslashes.

[Addslashes] is not the best way to escape data. The most important reason is security. addslashes can lure you into a false sense of security. As Chris Shiflett points out, there are situations that addslashes doesn't escape. Use mysql_real_escape_string instead.

Ivo also talks about the advantages of using the right function and suggests another even more secure way too - PDO.

Ivo Jansch has a reminder for developers when they're putting user data into their databases - don't use addslashes.

[Addslashes] is not the best way to escape data. The most important reason is security. addslashes can lure you into a false sense of security. As Chris Shiflett points out, there are situations that addslashes doesn't escape. Use mysql_real_escape_string instead.

Ivo also talks about the advantages of using the right function and suggests another even more secure way too - PDO.

Chris Shiflett points out an unexpected SQL injection possibility as presented by Alexander Andonov for PHP (involving mysql_real_escape_string).

The focus of the article is stressing the importance of filtering input and escaping output, as neither is a substitute for the other, but he does so very clearly with specific examples [...] A number of example exploits are supplied for each case, and he discusses which ones work, which ones don't, and why.

Chris also uses the post to link to Paul Reinheimer's post about add_slashes versus mysql_escape_string and his own post on the same topic.

Chris Shiflett points out an unexpected SQL injection possibility as presented by Alexander Andonov for PHP (involving mysql_real_escape_string).

The focus of the article is stressing the importance of filtering input and escaping output, as neither is a substitute for the other, but he does so very clearly with specific examples [...] A number of example exploits are supplied for each case, and he discusses which ones work, which ones don't, and why.

Chris also uses the post to link to Paul Reinheimer's post about add_slashes versus mysql_escape_string and his own post on the same topic.

Ilia Alshanetsky also has hos own look today at the "mysql_real_escape_string versus addslashes" debate that's going on, looking more at why there's even an issue here (with addslashes).

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes().

He shows code examples, creating a simple SQL injection that uses mysql_real_escape_string to cause the same issue - all based around the default characterset that the MySQL server uses. His suggested solution? Prepared statements... (like what things such as PDO offer)

Ilia Alshanetsky also has hos own look today at the "mysql_real_escape_string versus addslashes" debate that's going on, looking more at why there's even an issue here (with addslashes).

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes().

He shows code examples, creating a simple SQL injection that uses mysql_real_escape_string to cause the same issue - all based around the default characterset that the MySQL server uses. His suggested solution? Prepared statements... (like what things such as PDO offer)

In his latest blog entry, Chris Shiflett looks at a debate that's been going for a while now - addslashes() versus mysql_real_escape_string().

Last month, I discussed Google's XSS Vulnerability and provided an example that demonstrates it. I was hoping to highlight why character encoding consistency is important, but apparently the addslashes() versus mysql_real_escape_string() debate continues. Demonstrating Google's XSS vulnerability was pretty easy. Demonstrating an SQL injection attack that is immune to addslashes() is a bit more involved, but still pretty straightforward.

The reminder of the post explains the difference, how how protects you when the other doesn't (addslashes), and a simple example of how something like that could be accomplished, including code...

In his latest blog entry, Chris Shiflett looks at a debate that's been going for a while now - addslashes() versus mysql_real_escape_string().

Last month, I discussed Google's XSS Vulnerability and provided an example that demonstrates it. I was hoping to highlight why character encoding consistency is important, but apparently the addslashes() versus mysql_real_escape_string() debate continues. Demonstrating Google's XSS vulnerability was pretty easy. Demonstrating an SQL injection attack that is immune to addslashes() is a bit more involved, but still pretty straightforward.

The reminder of the post explains the difference, how how protects you when the other doesn't (addslashes), and a simple example of how something like that could be accomplished, including code...