magic_quotes_gpc & str_replace slashes

BEFOR

this is php4

function escape($message) 
        {
                $find=array("_",'?','$',"!","&","%","'",'"');
                $replace=array("\_","\?",'\$',"\!","\&","\%","\'",'\"'); 
                return str_replace($find,$replace,$message);
        }
$messageready = escape($message);

Part of the script relies on magic_quotes_gpc On On

While another part relies on the htaccess command: php_flag magic_quotes_gpc off
(preg_match to see quotations -- which I cannot redo for some time)

However lately -- discovered that doing an INSERT on $messageready is omitting the slashes. While doing a PRINT on $messagesready gives the backslash before the insert.

But the problem is that the phpinfo seems to have propogated since development, months ago,

from:
magic_quotes_gpc On On

to:
magic_quotes_gpc Off On // do to htaccess command

Question: will placing a php.ini file with 'magic_quotes_gpc On On' within that same script folder do it? Also, will it too propogate into local 'off' position?

Is there an easier, simpler way that addresses the above characters, realizing this will be done across multiple sites? mysql_real_escape_string does not address % and _ and this is a financial site.

laserlight

BEFOR wrote:
Is there an easier, simpler way that addresses the above characters, realizing this will be done across multiple sites? mysql_real_escape_string does not address % and and this is a financial site.

1. Set magic_quotes_gpc to off, everywhere.
2. Switch to the MySQLi extension or the PDO extension and use prepared statements. If you must use the MySQL extension, then use mysql_real_escape_string for string data.
3. If the data is to be used in conjunction with LIKE, use str_replace to escape % and .

BEFOR

1. Set magic_quotes_gpc to off, everywhere.

Local and Master?

2. Switch to the MySQLi extension or the PDO extension and use prepared statements. If you must use the MySQL extension, then use mysql_real_escape_string for string data.

For validating a comments form, this doesn't seem easy. MySQLi sounds like almost an entire rewrite? What would this actually give, and I'm not sure even after seeing the documentation. Would this somehow avert the backslash being omitted and if so how?

3. If the data is to be used in conjunction with LIKE, use str_replace to escape % and .

Not being used with LIKE, but nonetheless would like to escape the % and the
Isn't the % part of some injection/malicious attempt schemes?

laserlight

BEFOR wrote:
Local and Master?

Yes.

BEFOR wrote:
For validating a comments comments form, this doesn't seem easy. MySQLi sounds like almost an entire rewrite? What would this actually give, and I'm not sure even after seeing the documentation.

Well, you certainly have to consider carefully before a rewrite. The advantage is separation of SQL statement and data. The key problem with directly embedding data in SQL statements is that it becomes possible for specially crafted data to change the meaning of the SQL statement. Escaping the data properly avoids that, but the use of prepared statements side steps it completely.

BEFOR wrote:
Would this somehow avert the backslash being omitted and if so how?

You want the extra backslash to be omitted. The point is to prevent SQL injection, not add backslashes.

BEFOR wrote:
Not being used with LIKE, but nonetheless would like to escape the % and the _

If you do that, I believe that you would actually corrupt the data since the escape characters would be saved in the database when they should not be saved.

BEFOR

Laserlight, I do appreciate your help here. But I have to admit, you now have me a bit confused.

Originally Posted by laserlight
You want the extra backslash to be omitted. The point is to prevent SQL injection, not add backslashes.

Isn't inserting with a single backslash the traditional approach to preventing attacks? Be it a \ prepend with mysql_real_escape_string or by str_replace ? Are you saying to have a single backslash and no greater?

The \ entered from the form field won't get by the scripted preg_match
(which would otherwise amount to the second backslash).

Originally Posted by laserlight
(on escaping the %)...If you do that, I believe that you would actually corrupt the data since the escape characters would be saved in the database when they should not be saved.

Just to be clear, you are saying the the % should not be saved as \% Is this right? What about the other characters listed above initially? And I thought this is a layer of protection.

laserlight

BEFOR wrote:
Isn't inserting with a single backslash the traditional approach to preventing attacks? Be it a \ prepend with mysql_real_escape_string or by str_replace ? Are you saying to have a single backslash and no greater?

Yes. With the use of prepared statements, you should leave the data untouched. Rather, you would bind them to placeholders.

BEFOR wrote:
Just to be clear, you are saying the the % should not be saved as \% Is this right?

Yes.

BEFOR wrote:
What about the other characters listed above initially? And I thought this is a layer of protection.

Only the single quote looks relevant. Of course, I am assuming that the other characters don't have some other special meaning with respect to your code, e.g., like how forum bbcode might be interpreted at some point even though it has nothing to do with SQL.

BEFOR

I'm sorry, still not getting clarification.

a) so ONLY with prepared statements -- leave all special characters untouched?

b) if not prepared statements -- prepend with ONLY single backslash inserted before the special characters?

c) important - which might be deciding factor -- if not using prepared statements and am preventing the \ backslash via the current preg match from going beyond the comment form field -- does the single backslash need to be entered in the mysql table ? I guess the question is, what else in the way of special chars could act harmfully. Thus, the idea of prepending all chars listed initially here with the single \ -- which I was under the impression helps prevent malicious attacks.

laserlight

BEFOR wrote:
a) so ONLY with prepared statements -- leave all special characters untouched?

Yeah. If you have to use an escaping function like mysql_real_escape_string then you will of course be altering the data.

BEFOR wrote:
b) if not prepared statements -- prepent with ONLY single backslash?

I'm not sure what you mean by this: if you are not using prepared statements then you should use an appropriate escaping function like mysql_real_escape_string or the conversion of data to say, a numeric type. You should not be concerned with precisely how the string escaping function works, unless one is not available.

BEFOR wrote:
c) important - which might be deciding factor -- if not using prepared statements and am preventing the \ backslash via the current preg match -- does the single backslash need to be entered in the mysql table ?

What single backslash are you talking about? If there is no backslash in your input because you have filtered it in a previous step then well and good, but at this point you should still stick to normal techniques of SQL injection prevention. This is precisely the kind of extra layer of protection that you should be using.

BEFOR

You should not be concerned with precisely how the string escaping function works, unless one is not available.

As I said I have to escape the % so maybe I do have to be concerned. Which led me to str_replace and the \

If there is no backslash in your input because you have filtered it in a previous step then well and good, but at this point you should still stick to normal techniques of SQL injection prevention. This is precisely the kind of extra layer of protection that you should be using.

"normal techniques of SQL injection -- Isn't a primary reason for the \ backslash insertion is that it causes unintended seperation for the potential sql injector whenever these characters are entered?

laserlight

BEFOR wrote:
As I said I have to escape the % so maybe I do have to be concerned.

No, you don't. If you are using a string escaping function, then it should be used before you escape those characters.

BEFOR wrote:
"normal techniques of SQL injection -- Isn't a primary reason for the \ backslash insertion is that it causes unintended seperation for the potential sql injector whenever these characters are entered?

What do you mean?

BEFOR

No, you don't. If you are using a string escaping function, then it should be used before you escape those characters.

But mysql_real_escape_string does not address the %

Originally Posted by BEFOR
"normal techniques of SQL injection -- Isn't a primary reason for the \ backslash insertion is that it causes unintended seperation for the potential sql injector whenever these characters are entered?

Originally Posted by laserlight
What do you mean?

Once inserted into the table, special characcters such as \$ and \% along with the others cannot be used to run code to carry out further attacks. If the special characters are inserted without the \ then its easier to run scripts from within the table.

bradgrafelman

BEFOR wrote:
Once inserted into the table, special characcters such as \$ and \% along with the others cannot be used to run code to carry out further attacks. If the special characters are inserted without the \ then its easier to run scripts from within the table.

Er, what?

For one, '%' and '$' aren't "special characters" - they're just characters.

Second, there is no special sequence of characters you can insert into a column in a MySQL table that will suddenly turn the MySQL server into the next Terminator and start maliciously executing code all over the place.

BEFOR

bradgrafelman,

Hmmm. Terminator...Kirk. I'm seeing a common theme here. :queasy: Now those are special characters!

laserlight;10972125 wrote:
1. Set magic_quotes_gpc to off, everywhere.
2. Switch to the MySQLi extension or the PDO extension and use prepared statements. If you must use the MySQL extension, then use mysql_real_escape_string for string data.

I have decided to go with mysql_real_escape_string for now and ignore the % as mysql_real_escape_string doesn't see this as harmful, and I'm sure it knows better.

Above, should magic_quotes_gpc be "off" for both local and master even with mysql_real_escape_string, or was this in reference to MySQLi/PDO?

Just want to be sure because I can't tell when mysql_real_escape_string is inserting to the table properly (no backslash or chars added -- so how to you tell without "visual evidence"?)

laserlight

BEFOR wrote:
Above, should magic_quotes_gpc be "off" for both local and master even with mysql_real_escape_string, or was this in reference to MySQLi/PDO?

It should be set to off. Period.

BEFOR wrote:
Just want to be sure because I can't tell when mysql_real_escape_string is inserting to the table properly (no backslash or chars added -- so how to you tell without "visual evidence"?)

One way to tell is to input data that contains a single quote. If magic_quotes_gpc is turned on, this quote would arrive escaped, and then when you use mysql_real_escape_string, the backslash used to escape the quote will itself be escaped, as will the quote once again. Thus, when viewing the output, you will observe that it appears escaped when it should not be.

BEFOR

okay,

doing a PRINT on the comment field input (before insert & without mysql_real_escape_string) it is not backslashed (escaped) so magic_quotes_gpc must be OFF.

applying mysql_real_escape_string and there is the single backslash before ea single quote (again this PRINT is before insert) so we must be in business.

If magic_quotes_gpc is turned on, this quote would arrive escaped, and then when you use mysql_real_escape_string, the backslash used to escape the quote will itself be escaped, as will the quote once again. Thus, when viewing the output, you will observe that it appears escaped when it should not be.

I assume you mean table output.

apologies for laboring this, and I much appreciate the help laserlight.