Page 1 of 1

Prohibit include() in shared environment

Posted: Wed Feb 08, 2006 3:46 pm
by successor
Following setup:
A platform based in / which manages authentication etc. Password for db-access is stored in /config.php which is included by index.php.
After authentication this platform (actually the index.php) includes /modules/<mod_name>/index.php. The db-connection is demolished prior but the problem is that the admin of the module could simply include(../../config.php) and has access to the password of the db.

Is there a way to figure out, which script has included a file? Currently I'm setting a variable with a shared secret, which config.php checks and which is deleted before including the module. There has to be a better way...

Posted: Wed Feb 08, 2006 4:14 pm
by Christopher
It seems like the only way to really protect the file would be to serialize it and encrypt it and then load it and reverse the process. Even if they include() does not work because of logic in the config.php file, they could still just read the file with something like passthru().

Posted: Thu Feb 09, 2006 6:20 am
by Jenk
deny the php process access to any other folder but the users own (this canbe done as CGI-BIN)

Posted: Thu Feb 09, 2006 1:52 pm
by josh
You could use an open_basedir restriction:

http://us3.php.net/features.safe-mode

Run your modules under a virtual host that an open basedir as "." (the working directory) and disable chdir(), this will force the module's admins to work within their folders. Be aware open_basedir can also be bypassed with cURL so disable that as well, but you may have bigger problems if you cannot trust the module admins, functions like exec() have hte potential to trash your server.

Posted: Sun Feb 12, 2006 11:28 pm
by sp2hari
Run your modules under a virtual host that an open basedir as "." (the working directory) and disable chdir(), this will force the module's admins to work within their folders. Be aware open_basedir can also be bypassed with cURL so disable that as well, but you may have bigger problems if you cannot trust the module admins, functions like exec() have hte potential to trash your server.
But wont a simple file browser which opens the file directly can read the code
Like

Code: Select all

<?php
$contents=file_get_contents("/var/www/html/db_config.php");
echo $contents;
?>

I afraid that the above code will give out the password even if the above metioned things are done ,even though i haven't tried it.

Posted: Mon Feb 13, 2006 12:12 am
by josh
No, did you even read the link I provided?

Posted: Mon Feb 13, 2006 12:22 am
by Benjamin
I don't think this is a PHP question. I think it's a Unix permissions issue. I might be wrong, but I think this is the wrong way to go about doing something like this.

Posted: Mon Feb 13, 2006 3:14 am
by Maugrim_The_Reaper
What you talking about hiding is database credentials from your own server. That's getting a little extreme. Why do they need to be hidden? Do you not trust your developers?

If you are using 3rd party modules for a system like a CMS then you either take them on trust or do not install them. If you trust them and check if anyone has had any issues with them beforehand.

No it is not that way

Posted: Thu Feb 16, 2006 3:23 am
by sp2hari
HI,
What you talking about hiding is database credentials from your own server. That's getting a little extreme. Why do they need to be hidden? Do you not trust your developers?
It is not that we dont trust our developers but we try many things in a single server and each team wants to keep it's database
secure from the other teams.

:cry:

Posted: Thu Feb 16, 2006 4:03 am
by feyd
each team wants to keep it's database secure from the other teams.
That's sad. Real sad.