php ver. 5 +mysql_real_escape_string

[_matrix_]

Should mysql_real_escape_string work with php ver. 5

Thanks

[kromey]

Yes, it does. Are you having a problem with it, or was this more of a "Will my script still work if I upgrade to PHP 5" question?

[_matrix_]

I thought it should work ..

problems yes .. its not escaping the characters .. but same script is fine on php ver. 4

function ValidateInput($value) {
    $value = mysql_real_escape_string(strip_tags(trim($value))); 
    return $value; 
} 

Cheers

[kromey]

Do you have an open connection to your MySQL server already? mysql_real_escape_string only works if you've already opened a connection to a MySQL server. Are you getting any errors? Make sure error reporting is turned on or else you might not know.

[mrsmiley]

I use it on my PHP5 system successfully, but then I also use the mysqli version as well.

[_matrix_]

a connection is made as the data is being input .. just not escaped.

Tried addslashes as well, also not working.

in the file .htaccess I have disabled magic_quotes_gpc using:

php_flag magic_quotes_gpc off

Maybe thats the problem?


Thanks

[kromey]

Nope, that's not the problem at all.

Question: how do you know your strings are not being escaped?

[danh2000]

This may throw a spanner in the works, but consider using prepared statements with mysqli or pdo - much safer - you don't have to worry about the escaping then.

[Kailash Badu]

The question still is why mysql_real_escape_string is not working. do you care to show us the code?

[_matrix_]

The basics of the code:

The function:

function ValidateInput($value) { 
    $value = mysql_real_escape_string(strip_tags(trim($value))); 
    return $value; 
} 

the update

    foreach($_POST as $key=>$value){
    $_POST[$key] = ValidateInput($value);
    }

    $sql = mysql_query("UPDATE users SET email='".$_POST['email']."', msn='".$_POST['msn']."', icq='".$_POST['icq']."', yahoo='".$_POST['yahoo']."', aim='".$_POST['aim']."', about='".$_POST['description']."' WHERE userid='".$_SESSION['userid']."'")or die(mysql_error()); 

It updates the info with no errors, but stays as " rather than \"

The exact same script in PHP Ver. 4.4.3 works fine. The PHP Ver. 5 is another host.



Thanks

[kromey]

When you say it "stays as " rather than \"", how are you checking that? If you're looking at it in the database or are wondering why you're not having to run it through stripslashes when you retrieve it, then it is working as intended; likely your 4.4.3 host had magic_quotes_gpc turned on and you were in fact double-escaping your content.

Echo your array values immediately after escaping them and see what you get (you should see the '\' characters).

[_matrix_]

Hi,

4.4.3 host has magic_quotes_gpc turned off.

I know in PHP Ver. 5 because I check the database and the data hasnt been escaped at all.


Thanks

[kromey]

When you check the database, the only time you would see an escaping character is when you have double-escaped your data (e.g. by using mysql_real_escape_string when magic_quotes_gpc is turned on). You can verify the behavior by entering data that contains at least one ' character - if it enters into the database successfully, you are in fact escaping your data correctly.

[_matrix_]

Hi,

Really?

I asummed you would see \' in the database to show it has been escaped.

So I should have magic_quotes_gpc off?

and if the data inserts as ' rather than \' with no errors its good to go??

[kromey]

Yes, you should have magic_quotes_gpc turned off.

And yes, if your code can insert data with ' with no errors then you are good to go (it means your code is being properly escaped and thus SQL injection will not work).

[_matrix_]

That I did not know .. I assumed you should have \' to show it had been escaped.

Thanks!

[kromey]

Nope - just like PHP strips out the escaping \ when echoing a string, MySQL strips it out when inserting it into the database. Those characters are only dangerous when in SQL queries, so once they've gotten past that stage there's no longer any danger.

[_matrix_]

So in that case, there is no need to stripslashes then?

unless you maybe use addslashes instead?


Thanks

[kyberfabrikken]

So in that case, there is no need to stripslashes then?
unless you maybe use addslashes instead?

mysql_real_escape_string essentially does the same as addslashes. You use either addslashes or mysql_real_escape_string - not both. In either case, you do not use stripslashes on the output - Only on input. If you have magic_quotes turned on, you do not use addslashes or mysql_real_escape_string on input, because it has already been done.

[siteguru]

Is it not safer to check whether magic quotes is On, strip slashes if it is, then do your own validation/escaping? This way you always know exactly the status of your data. Simplified example below ...

function strip_magic_quotes($arr)
{
    foreach ($arr as $k => $v)
    {
        if (is_array($v))
        {
            $arr[$k] = strip_magic_quotes($v);
        }
        else
        {
            $arr[$k] = stripslashes($v);
        }
    }

    return $arr;
}

if (get_magic_quotes_gpc())
{
    if (!empty($_GET))    { $_GET    = strip_magic_quotes($_GET);    }
    if (!empty($_POST))   { $_POST   = strip_magic_quotes($_POST);   }
    if (!empty($_COOKIE)) { $_COOKIE = strip_magic_quotes($_COOKIE); }
}

$conn = etc. // make your Mysql connection

$data = $_POST['data'];

$sql = "INSERT INTO Table (Field) VALUES ('". mysql_real_escape_string ($data) ."')"; 

[kyberfabrikken]

Is it not safer to check whether magic quotes is On, strip slashes if it is, then do your own validation/escaping? This way you always know exactly the status of your data.

Yes, certainly. And if you have PHP5, I would further suggest that you use prepared statements/bound parameters instead of manually escaping all values. It's safer, it's easier and in case of PDO, it's portable too. That's like three bonuses in one.

[kromey]

That's like three bonuses in one.

I like 3-for-1 deals!

[cranial-bore]

Is it not safer to check whether magic quotes is On, strip slashes if it is, then do your own validation/escaping? This way you always know exactly the status of your data.

Personally I've always found this to complicate things. For example you may have a class that inserts into a database. The source of that data may be GPC, or it may have come from elsewhere in the script, unaffected by magic quotes.
In those cases checking the status of magic quotes won't help unless you also know the source of the data.

I prefer to turn MQ off (get a new host if you can't) and explicitly escape.

[kromey]

I prefer to turn MQ off (get a new host if you can't) and explicitly escape.

Sadly, not always an option. I just have an include before any of my processing that checks the status of magic_quotes_gpc and, if it is set, runs through each of GET, POST, and COOKIE stripping out the slashes.