On Sat, February 3, 2007 9:32 am, Ken Kixmoeller -- reply to ken@xxxxxxxxxxxxxx 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
