On Sat, February 3, 2007 9:32 am, Ken Kixmoeller -- reply to
[EMAIL PROTECTED] wrote:
>
> On Feb 2, 2007, at 6:59 PM, Richard Lynch wrote:
>
>> Putting PHP source into MySQL is the WRONG way to go for security
>> and
>> efficiency...
>
> Thank you, Richard -- I appreciate your advice.
>
> Here is a qualifier: I'm not putting any core code into tables, just
> code which generates page content. The access rights to that page
> content, as well as security code and application objects are not
> there. That code is off of the web path, called by functions. No SQL
> is in tables. So maybe I shouldn't have said "security."
>
> With that in mind -- I would really appreciate it if would help me
> understand your comment or point me to a resource which will. I have
> read a bunch of stuff on security, but no resources led me to believe
> that I was on a wrong path, though none of them followed the path I
> am on. It isn't too late for me to change.

The problem is that now instead of needing to protect your PHP files
from arbitrary code execution attacks, you need to protect your PHP
files *and* your database content, so you've just doubled the number
of potential holes, roughly speaking.

It doesn't matter if YOU put "core code" into your DB or not -- If
somebody manages to break into your DB, they can put whatever code
they want, and you're just going to execute it blindly.

In terms of performance, running a query to get some PHP snippet and
then using eval on it is probably not going to hold up under any kind
of load...  Or maybe it will -- Seems like eval should be expensive,
but perhaps I'm just remembering what it cost in Lisp...

-- 
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

Reply via email to