Would allowing " and \ cause SQL Injection

[kill_bill_gates]

I was wondering if allowing " and \ in the username or password field would cause SQL injection. Could somebody explain me this one and tell me what does magicquotes do?

Thanks a lot in advance...

[Pc_Madness]

Ahhh... no I don't think it would as long as you use Mysql_real_escape_string() around the input data or whatever it is, as it'll escape every " or \ in the string.

visualAd is the pro on this though I think. :\

[visualAd]

Magic quotes is evil. It auto magically adds slashes to any quotes found in outside data, such as POST, GET and COOKIE. The problem is, you cannot always rely on it being on.

Worse, if you are relying on magic quotes to protect you form SQL injection exploits, it will give you a false sense of security. While it works ok with MySql some other databases such as MsSql, Access and Foxpro do not use a backslash to escape quotes.

Fortunatly you can test whether magic quotes is on and undo its damage if neccessary. Two versions of the stripslashes and addslashes functions which test for the magic qutoes:

/**
 * Remove slashes form a previously escaped string
 * only if magic quotes is turned on.
 * @param string $string
 */
function stripslashes_safe($string)
{
    if (get_magic_quotes_gpc()) {
        return stripslashes($string);
    } else {
        return $string;
    }
}

/**
 * Escape quotes in a string using backslashes only if
 * magic quotes is turned off.
 * @param string $string
 */
function addslashes_safe($string)
{
    if (! get_magic_quotes_gpc()) {
        return addslashes($string);
    } else {
        return $string;
    }
} 

[CornedBee]

Generally, I treat everything I get from the user to a stripslashes_safe-like function and then use prepared queries for the actual action. PEAR:B and PHP DBO can emulate prepared queries for databases that don't support them (such as MySQL pre-4.1).

A prepared query is a query that contains question marks:

SELECT * FROM table WHERE name = ?

Then you can substitute these parameters with actual values. The cool thing about this is that the database driver takes care of correct quoting and escaping. All you have to do is make sure the parameters aren't already quoted.

[kill_bill_gates]

(I'm using MySQL)

Would using addslashes() work?

[CornedBee]

addslashes() correctly escapes strings for MySQL, but beware the stuff we talked about.

[Matt_T_hat]

I mostly allow every last character in passwords and the first thing I do is MD5 (one way encrypt) so it doesn't matter but no one can read the password if they get the database.

With user names again this is a special case and I would carefully do a replace for all the characters I wanted to allow and replace with HTML escape codes so that no HTML injection can hurt things (HTML injection also called a site to site scriptting attack is used with javascript and often used to steal cookies.)

In all other cases I would clean up all input that might come from a user (even hidden values in forms (trust nothing)) so that the SQL sequence is safe.