On Mon, 2007-06-04 at 23:25 +0900, Dave M G wrote:
> Robert ,
>
> Thank you for your quick reply.
>
> If it's okay, I'd just like to clarify the points you raise.
>
> >> I just want to double check here what to do. Should I disable magic
> >> quotes on my server?
> >>
> >
> > Not unless you're certain you don't have any script that rely on magic
> > quotes. If you do, then they will become open security holes.
> >
> The only scripts I have are the ones I put there myself. So if I conform
> to the no magic quotes standard, then I should be safe, right?
Yes... as long as they all properly escape data.
> >> Also, I'm developing code that I hope others can use. For the purposes
> >> of portability, is it safe to assume that most environments will have
> >> magic quotes off, and build for that?
> >>
> >
> > No, you should check the ini setting in your code and react accordingly.
> >
> Sorry, I don't quite follow you here. If I turn magic quotes off on both
> my testing environment and my server, as is "preferable" according to
> the manual, then my ini file will conform to that.
>
> But I don't see how that relates to the portability of the code. As much
> as possible, I'd like to have others be able to run my scripts with
> minimum hassle.
>
> If I make my development environment and my own web hosting server
> conform to the "preferable" set up, but most servers default to having
> magic quotes on, then won't my code break on most people's servers?
If you want other people to run your scripts then they may come from
different hosting configurations. Some will have magic quotes enabled,
some will not. Since you want a minimum of hassle, and you want to reach
the widest possible group, YOU need to check the magic quotes ini
setting in your script and do the right thing based on what you receive.
For instance if magic quotes are disabled, you know to escape any
questionable data coming from $_GET, $_POST, etc. However if your code
is run on a server with magic quotes enabled, then single quotes and
stuff will already be escaped. This has a couple of issues:
1. It's not safe since it doesn't use your database's specific
escaping policy. This is important due to character sets.
2. If you just balatantly apply the databases escaping policy some
characters will get escaped twice meaning you'll actually see the
escape character added by the magic quotes mess.
The best way to handle this is to remove magic quotes escaping from
retrieved values and then apply your database's escaping mechanism. If
you cannot ascertain the source of the data being used in a query,
you're better safe than sorry and should apply your database's escaping
even if it means you'll get double escaping.
> >> So I should disable magic quotes on my testing environment and do my own
> >> escaping?
> >>
> >
> > Yes.
> >
>
> Okay... but I'm still confused as to how this impacts the potential for
> my code's portability as described above.
Your environment is not necessarily everyone else's environment. See
above :)
> >> While I'm asking about escaping, is converting characters like
> >> apostrophes and ampersands to hex characters before storing them in a
> >> MySQL database a safe way to go?
> >>
> >
> > No, use the proper escaping mechanism offered for your particular
> > database.
> Since my database is MySQL, does that mean using addslashes() and
> stripslashes()? In other words manually doing what magic quotes was
> doing automatically?
Neither! It means using mysql_real_escape_string():
http://www.php.net/manual/en/function.mysql-real-escape-string.php
> Just for my own education, is it insecure to use hex codes to store
> apostophes and other special characters in the case of MySQL? Can
> someone inject a workable MySQL command into my database if all
> apostrophes and other non-alphanumeric characters are converted to hex?
Escaping handles the security implications. If you want to go ahead and
do something weird like converting quotes and stuff to hex codes that's
fine. But understand that'll you're just creating you're own escaping
system since whatever you use to denote a hex converted character will
need to be escaped when it should be considered literal. As such, MySQL
is backed by fast and time/user-tested C code. Your method will be prone
to errors and inefficient implementation and still may have issues due
to character set issues.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
