magic_quotes_gpc会救我吗？

Question

There is a (ugly)project I was asked to help with by doing a specific task. The thing is, I don't have any control over the other files in the site much less over the server configuration. Some data I'm going to use comes from a query like this:

'SELECT * FROM table where value like "'.$unsafe.'"';

$unsafe is an unescaped value coming from $_POST or $_GET. I checked the server, is PHP5.1.6 and has magic_quotes_gpc On so the data is being auto escaped. Is this query breakable? Being $unsafe between colons gives me the impression It cant be broken but maybe I'm missing something. I know magic_quotes_gpc is deprecated because of its insecurity so I'm concerned about it, not because of the application security which fails every where but for my own knowledge.

EDIT: I'm aware of the security implications of *magic_quotes_gpc* and I never use it in my own projects. I always use parameterized queries to avoid injection but this time I was asked to add a very specific pice of code in a friend/client project, so I cant change what is already done. I'd like to know if there is a specific value I can use to create an injection so I can illustrate my friend why he should change it.

Answer 1

if the DB is mysql use mysqli_real_escape_string() instead, if the PHP version is very old you can use the mysql_real_escape_string (not recommended at the moment).

even if the variable is between colons it can be injected, you just need to close the colons inside the value of the variable and then inject whatever you want afterwards.

Answer 2

With regard to your edit: You asked "I'd like to know if there is a specific value I can use to create an injection so I can illustrate my friend why he should change it."

According to the manual page for mysqli_real_escape_string() , the characters it escapes are as follows:

NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.

The old mysql_real_escape_string() function also escapes the same characters.

This gives you a starting point as to which characters can be used to do injection attacks in MySQL. Magic quotes only escapes the quote characters and the slash character, which clearly leaves several gaping holes that can be exploited.

In an easy world, the above information would be enough for us to fix the escaping by doing a string replace on the remaining unescaped characters.

However, both the real_escape functions also require an active database connection for them to work, and this leads us to a further complication: character sets.

Further attacks are possible if the database has a different character set to PHP, particularly with variable-length character sets such as UTF-8 or UTF-16.

An attacker who knows (or can guess) the character set that PHP and the DB are using can send a crafted injection attack string that contains characters that PHP would not see as needing escaping, but which would still cause succeed in hacking MySQL. This is why the real_escape functions need to access the DB in order to know how to do the escaping.

Further resources:

• Php & Sql Injection - UTF8 POC
• SQL injection that gets around mysql_real_escape_string()

I hope that gives you a few pointers.