Re: magic_quotes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, November 29, 2006 11:55 pm, Johannes Lindenbaum wrote:
> But... magic_quotes.
> If my understanding is correct magic quotes will give ', " and \ (for
> ASCII characters, e.g. \n) a preceding backslash to escape it. I also
> see that magic_quotes_gpc() is On by default. So all data in $_POST
> and
> $_GET etc. has escaping backslashes.

Yes, but the problem is that *ALL* data in GET/POST has the escaping
backslashes as if it were ASCII data, and it may *NOT* be ASCII data.

It might be UTF-8.
It might be UTF-16.
It might be some charset you've never even heard of.

And guess what?

addslashes() on non-ASCII data, UTF-8 for example, is like a condom
with a hole in it.

> If in a .htaccess I should set
> php_flag magic_quotes_gpc Off
>
> That would lead to $_POST data like Jingle's Bells to be passed as
> Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data
> gets
> written into a MySQL table to which I perform addslashes().

Switch to:
http://php.net/mysql_real_escape_string

> And on
> retrieval stripslashes().

No, no, and no.

You do *NOT* use stripslashes() on the data coming OUT of MySQL.

Unless you've already screwed up and done BOTH addslashes() and
MagicQuotes, which in essence did addslashes() twice, so you added
bogus data to your database.

Jingle's Bells
+ [magic quotes] ===> Jingle\'s Bells
+ [addslashes]   ===> Jingle\\\'s Bells
========================================
Corrupt data in MySQL: Jingle\'s Bells

The whole point of this escaping is to identify characters that MySQL
should store as data, rather than interpret as "non-data"

Jingle's Bells
+ [magic quotes *OR* addslashes *OR* mysql_real_escape_string]
=====> Jingle\'s Bells
==============================================================
Correct data in MySQL: Jingle's Bells

Once you've done that correctly, what MySQL actually stores is the
data, not the escapes it needed to identify the data.

So if you find yourself using stripslashes() on your MySQL data to get
it "right", then, in reality, you've already screwed up and stored
non-data as data.

So go back and fix your script to NOT double-escape the input, then
fix your bad data in MySQL to NOT have non-data (\ escape character)
as part of your data.

This is going to be a major pain, I know, but you'll only make it
worse the longer you put it off.

It will be a whole lot easier if you can "freeze" the input routines
to not take anything in between the time you fix those and when you
fix the data within the database...

If not, you'll want to note EXACTLY which rows have corrupted extra
backslashes and which do not, so you can apply stripslashes() to only
the corrupt data.

> If I keep on doing that - and just start coding with magic_quotes_gpc
> Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should
> they?

You are correct that turning off magic_quotes_gpc is a good way to
prepare for PHP 6.

This has been rant #53, brought to you by the character "\"
:-) :-) :-)

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux