Hi All,
I wanted to bring up a security issue that has been nagging at me for a while. I'm wondering if anyone has security concerns about being able to access http://mymoodlesite/config.php even though it doesn't reveal anything in this simple manner. Since this file contains db password and system path info, it seems that it should be secured, no?
I am aware of apache filtering files that begin with '.ht' via the <Files> directive. Could this be extended to include config.php.
Another thought, might it be better to give all files not intended for direct viewing a different extension like say '.inc' for include, then use the apache <Files> directive to filter all such files from direct display?.
Any thoughts? Are my concerns unfounded?
Regards,
John
I had a go at using .htaccess to prevent access to configphp using
<Files config.php>
order allow,deny
deny from all
</Files>
and then adding
allow from MYIPADDRESS
But in either case I could not use the admin page.
I can't see any problem with it... the $CFG variable is explicitly reset at the top, and none of the sensitive info inside can be displayed via the web.
First of all - forgive me if I'm talking nonsense, but I'm not a web programmer 
I've once read somewhere (I think this was installation instructions of a php script, but I don't remember what script it was) that there is a danger involved in making the config file web-accessible. The solution employed by the person who wrote that script was to place the config file one level above the root directory (where the moodledata folder is).
Would this solve the problem (if it exists)?
I've once read somewhere (I think this was installation instructions of a php script, but I don't remember what script it was) that there is a danger involved in making the config file web-accessible. The solution employed by the person who wrote that script was to place the config file one level above the root directory (where the moodledata folder is).
Would this solve the problem (if it exists)?
I know where I've seen this warning about security problem - see the red IMPORTANT and the explanation at the very bottom of the page at http://popper.ractive.ch/popper/installation.php#poppercfg
Could someone who knows something about web applications and security check whether this popper guy has a point here?
Could someone who knows something about web applications and security check whether this popper guy has a point here?
Hmmm - he suggests that PHP could crash and show the contents of the page. PHP would have to crash in a pretty bizarre and specific way to show the content of a page like that, and then of course someone would have to be accessing the config.php at the same time.
I still don't think it's cause for concern (if it is then millions of websites have the same problem), but there are some changes I've been thinking about anyway that will remove even that chance.
The idea is to eventually modify config.php to do more work than it does now. Installation would be something like this:
How does that sound so far?
I still don't think it's cause for concern (if it is then millions of websites have the same problem), but there are some changes I've been thinking about anyway that will remove even that chance.
The idea is to eventually modify config.php to do more work than it does now. Installation would be something like this:
- Moodle files are uploaded.
- User visits http://mymoodlesite.com/config.php directly.
- Script looks for a file called site.php in the same folder (and creates one if it doesn't exist, using a form that leads you through the process).
- This file contains the configs for the main docroot and (for each of multiple sites) the site URL and the dataroot folder.
- Depending on the URL being used at the moment, config.php picks the appropriate info from site.php.
- It then looks in the matching dataroot for a file called config.php, which contains the database details. If this file doesn't exist yet, then again forms are presented to collect database details and create this file.
- All the other configuration data is stored in the database.
How does that sound so far?
This sounds good, but I'm confused about the config.php. Are you saying that there is possibly more than 1 config.php file (1 per site) or just more than 1 site.php file (1 per site)? Why wouldn't the site.php file contain the db details?
Well, it certainly would be simpler to have all the details in the site.php, but given that it will be within the Moodle tree there is still the remote problem with the file being read by others (even by other shell users) ...
The current idea is to use site.php only for less-important information (URL and system path), and hide the database info separately in the dataroot (I previously called this database info file config.php, but to avoid confusion let's call it dbsettings.php).
So, config.php looks in site.php, which tells it where to find dbsettings.php.
There may well be better ways of organising all this ... suggestions welcome!
The current idea is to use site.php only for less-important information (URL and system path), and hide the database info separately in the dataroot (I previously called this database info file config.php, but to avoid confusion let's call it dbsettings.php).
So, config.php looks in site.php, which tells it where to find dbsettings.php.
There may well be better ways of organising all this ... suggestions welcome!
Yea, the naming threw me. I get it now. That sounds good to me.
John
John
Someone told me to:
- write a dummy config.php with in it only the line:
- <?php include ("d:\foxIncludes\configMoodle.php") ?>
- then place the real config.php outside the web-tree
- then set the path to this real to include config
(Don't know if this makes sense, do it since as a kind of ritual)
That's a good idea! That is a very simple solution if you have access to files below web root!
For installs where you don't have access below webroot a different approach is needed. In my original post, I had suggested using apache filters. I finally found a snippet that works:
This regexp will disallow apache from serving any file named *.inc or *.inc.php
<FilesMatch ".inc(.php)?$">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
To make this work, we would need to rename include files to add .inc so this regexp works. So, config.php would become config.inc.php. Then any file that you want secured just need to be renamed. This snippet could go in the .htaccess file or in your httpd.conf. I have this working on my apache 1.3 install.
This would address the concern about apache somehow serving up the file when PHP has crashed and letting someone see the actual contents.
I don't know about windows users...
John
For installs where you don't have access below webroot a different approach is needed. In my original post, I had suggested using apache filters. I finally found a snippet that works:
This regexp will disallow apache from serving any file named *.inc or *.inc.php
<FilesMatch ".inc(.php)?$">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
To make this work, we would need to rename include files to add .inc so this regexp works. So, config.php would become config.inc.php. Then any file that you want secured just need to be renamed. This snippet could go in the .htaccess file or in your httpd.conf. I have this working on my apache 1.3 install.
This would address the concern about apache somehow serving up the file when PHP has crashed and letting someone see the actual contents.
I don't know about windows users...
John