Question

I’ve seen dozens of PHP snippets that go like this:

function DB_Quote($string)
{
    if (get_magic_quotes_gpc() == true)
    {
        $string = stripslashes($string);
    }

    return mysql_real_escape_string($string);
}

What happens if I call DB_Quote("the (\\) character is cool");? (Thanks jspcal!)

Aren’t we supposed to strip slashes only when get_magic_quotes_gpc() == true and the value originated from $_GET, $_POST or $_COOKIE superglobals?

Answer 1

Yeah, I’ve seen dozens of PHP snippets like that, too. It’s a bit sad.

Magic quotes are an input issue. It has to be fixed at the input stage, by iterating the GET/POST/COOKIES arrays and removing the slashes, if you need your app to run on servers using the foul archaic wrongness that is magic_quotes_gpc. The simple alternative is to detect the magic quotes option and die with a “your server sucks” error when set.

mysql_real_escape_string is an output issue. It needs to be run on the way out of the script, on content heading to the database, if you’re not using parameterised queries (which you should definitely consider).

These are two separate unrelated stages in the program. You can’t put them in the same function, tempting though it may be to try to encapsulate all your string processing into one box.

Aren’t we supposed to strip slashes only when […] the value originated from $_GET, $_POST or $_COOKIE superglobals?

Yes, exactly. Which is why the snippet you quoted is indeed harmful. Because tracking the origin of a string is impractical (especially as you might combine strings from different sources, one of which is slashed and the other not), you can’t do it in one function. It has to be two separate string handling functions called at the appropriate time.