NYCPHP Meetup

NYPHP.org

[nycphp-talk] un-escape db content using php or ADOdb functions

Hans Zaunere bulk at zaunere.com
Wed May 2 13:39:58 EDT 2012


Hi,

> Hi,
> I've read your interesting article:
>
http://www.nyphp.org/phundamentals/5_Storing-Data-Submitted-Form-Displaying-
Database

Ahh, an oldie but a goodie :)

> I have a couple of questions about the function fix_magic_quotes:
> 1) Why do you disable magic_quotes_gpc and magic_quotes_sybase via
> ini_set? Fixing the content escaped by magic quotes should be enough
> in my opinion, am I wrong?

magic_* anything is a bad idea - it's an infamous mistake that PHP made.

Explicitly escape what you need, based on the destination the data is going
to.

> 2) As far as I know, stripslashes is affected by magic_quotes_sybase,
> s  if magic_quotes_sybase is on, both addslashes and stripslashes work
> in a  sybase-style way. For this reason I don't think you need to use
> str_replace.

For databases (MySQL in particular), you must always use the database
specific escaping.  This means mysql_real_escape_string().  This is because
of character encoding.

> And finally a more general question: are you aware of any method for
> un-escaping content based on db-specific escape function? I mean
> something  kuje stripslashes but specific so: the counterpart of
> addslashes is stripslashes, is there any counterpart  for
> mysql_escape_string or for the adodb function qstr or the PDO quote
> function?
> I know that, in an ideal world, we don't need them but if an
> application has been build using a "escape everything" approach and
> you need to work with that, you need to unescape content when you
> don't use it in a query  and stripslashes doesn't work if you switch
> from addslashes to something  like adodb->qstr.

Yes, you should never need to "unescape" what you read from a database.  And
the problem you're facing here, is exactly why you should use the MySQL
escaping functions, rather than generic magic_*, addslashes, etc.

If you've inherited an application that does this, then it could be painful.
If it were me, I'd first run a script/process to clean up the existing data
as best as possible, and get away from these bad escaping practices.  Then
code the rest of the application correctly, using MySQL's real_escape()
function.

H





More information about the talk mailing list