Storing php code in a database (for use with eval)

[kael.shipman]

Hey everybody.

 

I've got a need to store php code in my database (among the text) that I parse out and execute with eval(), and had it encrypted at first, but have seen now that the decryption process (it's a custom encryption/decryption function set) adds a good half second or so to an already-slow load time. Given that I've taken fairly adequate steps to securing my database, do you suppose there would be a problem storing the code as plain text to shave off that extra time?

 

-kael

[btherl]

Well, "it depends"

 

Is the code so sensitive that someone who already has access to your database would gain additional power or information by having access to that code?

[kael.shipman]

No; I was just worried about the prospect of someone finding a way to put code into my database and have the site execute it. Like I said, I feel that the database is adequately secured, but I was more wondering about a best-practices approach to the situation. Is it pretty standard procedure to store code in a database like this?

[trq]

Is it pretty standard procedure to store code in a database like this?

 

No. And I'de be more worried about people being able to inject code directly into eval. There is a saying that goes with eval, something like... "If you think you need to use eval, your probably thinking of the wrong solution".

 

Basically, its a pretty dangerous function if not handled well. Why you would need to create code dynamically is behond me, can you explain a little of why you think you need to store your code in the database?

[kael.shipman]

Yeah, I don't really like the prospect either, but I've got this fairly broad-scoped catalog site that I built and am managing (http://www.fireflyoutfitters.com), and I was trying to get around building separate pages for every little feature I wanted to add. To do so, however, I needed to include functionality that would allow me to add little tidbits of code here and there for those special features (to be honest, this is the first time I've ever actually needed to employ that functionality).

 

I suppose I could include an "if" statement in the main page whenever I need it, but my goal for the site was for management to be completely free of file browsing. I'm making a nice big web-based back end for it where you shouldn't have to mess with database language or PHP or anything, but with that comes the price of having to make everything as flat and standard as possible (hence my hesitation to include any special "if" statements).

 

I concede that perhaps it was poor design that led to this, but with failure comes experience, right? So back to the point: the php manual page for eval clearly states that the construct is for executing stored code. However, almost everything I've read about it has warned against it. Why ever would it still be available if it were indeed never to be used? The risk involved may be high when evaluating the potential consequences of failure, but what's the real probability that such consequences will ever be borne?

 

By the way, I'm only arguing in hopes of getting the most well-founded answers (i.e., not "Don't do it because I don't do it"). I fully acknowledge that there are those among you who know far more about this than I, so kindly continue to share your wisdom!

 

-kael

[per1os]

You wouldn't necessarily need "if" statements as to say.

 

For features or modules I would say that they should be housed outside the DB for easy modification of someone else, that would piss me off if I had to edit a database entry to update a feature or module to suit my needs.

 

But one way to do it is in the config file or a main function of the site that is required is include a new page like "addmodules.php" which in return goes into the database and looks at a modules table and see if they are "on" if they are on it grabs the name or location and than includes it from the modules/features directory. If it is off it is ignored.

 

That way it is really only a few lines of code which include a massive amount of code.

 

That is just my suggestion.

[kael.shipman]

Well, see the point is not to have to add or edit anything on the site, but to accommodate future additions, should the need arise. One of my big concerns here is making sure that the wysiwyg admin site still works after such a module has been created or edited. Given the basis of the wysiwyg editor on the actual site files, you can see that someone going into my files later and adding a module may disrupt the admin site, meaning they'd have to rebuild that, too. To avoid such a thing, I thought I'd let modules be added from inside the content, rather than outside. That way, they can be added along with the content.

 

I should probably clarify that I'm not looking for any future administrators to add huge new functionality to the site through these "modules". Just little things, like in this case a category window that gets its content from a different place in the database than the standard display window, or if you wanted to display the current product name at the top of some block of content.

 

Anyway, I think I've lost some steam on this particular venture, so I'm going to back off on it now. That's the kind of functionality that I can always add later, and I'd rather the site be safe than be experimental.

 

Thanks for all the advice!