Prohibit include() in shared environment
Moderator: General Moderators
Prohibit include() in shared environment
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...
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...
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
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.
But wont a simple file browser which opens the file directly can read the codeRun 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.
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.- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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.
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
HI,
secure from the other teams.

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 databaseWhat 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?
secure from the other teams.