are there security problems with database-stored php webpages?

[reages]

good day,

 

i've made some websites that stored the contents of the webpages (.php) in a database and would like to know if there are any major security problems with this approach?  the ff. are some steps i took to minimize compromise:

 

- restricted and filtered the page name to only a set of characters (a~z, A~Z, 0~9, <space>, -, _, .) and to a maximum number of characters (20 chars max).

- before executing the stored webpage (using eval()), unset()s all variables used to retrieve and process the stored webpage.

- i've randomized the variable name holding the content of the stored page (i've also thought of randomizing all the variable names but decided otherwise since the rest of the variables will be unset() anyway before the stored webpage is evaluated/executed).

 

please note that the webpages are properly filtered and converted to database-safe format before being stored and assume, for simplicity, that the webpages doesn't contain any malicious code.

 

regards.

[trq]

Letting any user inputted data into eval() without the proper precautions is always a little dangerous, In fact Id'e almost go as far as to say eval() in general is a bad idea. We would however need to see some code before we could possibly say any way or the other.

[Orio]

Man dont ever put user input code into eval(). No matter how many regex and filtering you use, you will always have a weak link.

Example- a way to use the exec function (or any other function that can be used maliciously) even if you try to filter it (using variable-functions):

<?php

$a = "ex"."ec";
$b = "<some command that will shut down your server or delete files etc')>";
$a($b);

?>

 

 

Simply don't do it.

 

Orio.

[reages]

first, thanks for the replies.

 

regarding the eval() issue, i'm sure that what i wrote was that what was eval()'d is the webpage stored in a database (w/c i have you assumed to be "clean" and, let me add, can only be updated by the webmaster).

 

any other issues?

 

regards.

[dbo]

I'd certainly agree that as a best practice it should be avoided, but eval does have a place. That being said this isn't necessarily one of them.

 

One place I've seen it used in the past is to give end users some ability to write some basic logic. Consider Drupal (opensource content management system). Users with certain privileges may create pages with some php code... how do you think this is pulled off? I'd wager to say eval. Only users who have been given the right privileges have the ability to do this, security layer 1. The php is then filtered so that it can't hurt the system (at least in theory) security layer 2. The fact of the matter is anything can be hacked. There is no such thing as 100% secure. It's just a matter of making the right decisions at the right times (ie not overusing eval) and coding security in layers... just like everything else.

 

One thing I've done in the past is write a class for verifying if user input is safe to be eval'd. Basically this splits the code into tokens and looks at each individual token to determine if the code is safe. Then function calls are compared against a list of allowable function calls. If it passes this then go ahead and eval the code... if it doesn't then don't. This way you can be sure that you're not allowing users to run system/exec type commands.

 

But again, there's a time and place to do this. I'm not saying eval is the safest thing in the world but it has it's place like everything else. What I would say is people who don't understand code injection and repercussions of using eval should not use it.

[reages]

thanks for sharing your thought.

 

again, eval()'d are pages updatable only by the webmaster.

 

how about we organize a bit, and divide the problem to two, in terms of user input (or lack of it):

1) the only input coming from the user is the page requested, ie, "index.php?p=1" or "index.php?p=grc-list" (please read my first post with regards to filtering and on how it, user input, won't reach the eval() function).

2) there would be input from the user, such as a fill-out form either to be stored on a database or to be emailed (again, filtered).

 

for now, please focus on only the first scenario.

 

regards.

[reages]

ps, please try not to focus on only the eval() issue.  how about the potential for crashing the server? or getting to expose php/server settings/parameters?

 

if there isn't any known potential problem with the first scenario, and/or you just want to point to a specific vulnerability/exploit regarding the second scenario (such as ways of bypassing/fooling known filter methods), just specify w/c scenario you're refering to.

 

regards.

[dbo]

Eval can be exploited. Other than that there aren't really any problems with storing stuff in the database. Other than the fact that if the connection to the database is down... your site basically won't work. But in most data driven environments out there today this isn't much difference than if your actual data isn't able to be generated due to failed db connections.

[reages]

thanks for the thought.  anyone else?  dispute?  agree?

 

as for the eval() issue, let's look at it in another way: could a filter that prevents sql injection or that is similar to what most boards use, ie phpbb, potentially prevent php injection?

 

regards.

[reages]

no more ideas? anything in the line of how it can be compromised? or be secured? anything specific?  how about "using non-latin characters bypasses any known method of input filtering" or "with the exception of an unpatched bug (such as buffer/heap overflow like in http://lists.virus.org/bugdev-0611/msg00016.html, though i think its already patched... maybe ), using htmlentities(), w/ ENT_COMPAT, prevents php injection". anything?

 

regards.