$_SERVER['DOCUMENT_ROOT'] - security issue???

[maxelcat]

Hi

 

I run versions of sites on a local server. For these the path to a mysql connection script is pretty simple: mysql_connec.php

 

On my live server, I put things out of the public directory - so this time the path is ../mysql_connect.php

 

I therefore have to have sections like this in my files = and whilst not complex, its a pain having to uncomment/comment lines depending on which server I am working because I keep forgetting!

 

//	require_once('../../workRecord/mysql_connect.php');    //online
require_once('mysql_connect.php');                              //local

 

Is there some way I can identify which server I am on so I don't keep having to do this. I was thinking of using something like this:

 

 

if ($_SERVER['DOCUMENT_ROOT']=="c:/web_root/blah/blah"){
require_once('mysql_connect.php');
}else{
require_once('../../workRecord/mysql_connect.php');
}

 

I am pretty sure this would work, but does this method present any security issues???

 

[chronister]

I have used $_SERVER['HTTP_HOST']... as in

 

if($_SERVER['HTTP_HOST'] == 'localhost'){
// local host code
}else{
// live server code
}

 

To the best of my knowledge, these server vars are not immune to modification... so I don't know what the "correct / safe" way is to do this.

 

 

[requinix]

To the best of my knowledge, these server vars are not immune to modification

It's kinda immune, kinda not. It depends on whether your web server is set up in a certain way.

 

With Apache there's a default web root for the default hostname. You can also configure VirtualHosts for additional domain names. If you do, Apache will look at the request from the browser and decide if the hostname given matches any sites it knows about; if so then the appropriate site's stuff gets executed.

However if the host doesn't match, Apache will send it to the first configured VirtualHost - regardless of whether it matches or not. So if your first hostname/site is your normal hostname/site, someone could trick your code into thinking it was running on "localhost".

(The solution is, when using virtual hosting, to configure a separate, "default" or error-message-only site as the first VirtualHost. Personally, since I don't care to conceal that I run Apache on my server I have it serve the stock 000-default site.)

 

SERVER_NAME is a good one to use. SERVER_ADDR works too but isn't as easy to deal with.

[maxelcat]

Thanks for the replies and - I think I understand!

 

Since I am running on a shared server, and was hacked abot 6 months ago (very painful!) I think I will stick to the "Do it by hand method".

[Anti-Moronic]

The problem here is not the security of $_SERVER variables but of your method for database connection.

 

You should have a abstract way of dealing with connections. Ideally, a config file (outside the web root) which contains database settings for localhost and as many other possible external databases. You then use a server environment directive which tells your script which connection to use. Many frameworks do this and so does Zend Framework.

 

Then it is very simple as all you do is set the environment (like 'development' or 'production') and you program you're script to use 'development' or 'production' database connection settings. You can also set this directive within htaccess which allows your script perfect scope for dealing with it. This is good if you don't have a common file your app is run through (like a front controller).

 

On security of checking these variables or any variables for that matter -

 

If you whitelist - i.e. checking if a value IS something - then I can't see any security issue.

 

For example, there is absolutely no security hole in this:

 

switch($_SERVER['DOCUMENT_ROOT']){

  case 'c:/web_root/blah/blah':
    //use connection 1
    break;

  case 'c:/somewhereelse':
    //use connection 2
    break

  default:
    exit; //or produce error because no matching docroot was found
}

 

However, what you currently have is an ELSE which means any blacklisted comparison is also passed on. It is like adding a 'default' to the above switch yet still providing a connection even though we have no idea what the current doc root is.

 

My advice is to follow the first few paragraphs and incorporate that into your apps. It's easy, secure, and far more maintainable than your current method.

 

[maxelcat]

Dear A-M

Just want to thank you for a really, really helpful post - the white list explantion was great too!

 

I will have to make sure that my local and live server setups mirror wrt their file structures, and then I'll easily be able to impliment what you have suggested

 

thanks again

[Anti-Moronic]

No problem Glad I could help!

 

There's little you can to avoid manual setup if you didn't produce the apps yourself. But if you did, I would suggest defining a clear, consistent file structure you can use for all of your apps, no matter the size or function. Will definitely increase your productivity and if you incorporate what I said above, things like this will be a complete non-issue which will allow you to do the more important stuff: making your fingers bleed.

 

In fact, I started using Zend almost exclusively due to this problem - having consistency among apps. It has definitely helped a lot. I can switch over to 'development' and have the correct connection settings used, but also have it print certain errors to screen and display debug info among many other environment specific controls.

 

If you download one of the frameworks, you should be able to see how they also do this which will hopefully help you in implementing something similar. Also, Zend Framework is what's called loosely coupled so you can even use one or two elements of it without using the entire framework!

 

Hope that helps.