Page 1 of 1

Is it safe to have an include file for connecting to MySQL?

Posted: Wed Oct 17, 2007 1:24 am
by Josh1billion
For example,

Code: Select all

// connect_to_mysql.php

$result = mysql_connect(localhost, "test", "test");
$result = mysql_select_db(blah blah);

Code: Select all

// index.php

include("connect_to_mysql.php");

$result = mysql_query("blah blah blah");
Would that be safe?

I know it wouldn't be possible for someone to remotely host their own index.php, to make their own query calls, because the include() in their remote index.php would fail because of the "localhost" in the first file.. but are there any other security flaws with this type of setup?

What if the "localhost" was the name of the actual server instead of "localhost"? Would they be able to make their own query calls with their own, remotely-hosted index.php?

Posted: Wed Oct 17, 2007 1:31 am
by Kieran Huggins
I've used that method, don't see anything wrong with it.

Other apps sometimes store connection information in an included file in the form of constants, which also works nicely.

At any rate, keeping it below the web root would not be a bad idea.

Posted: Wed Oct 17, 2007 1:40 am
by Josh1billion
Thanks for the input, Kieran. :)
Kieran Huggins wrote:At any rate, keeping it below the web root would not be a bad idea.
Do you mean having the connect_to_mysql.php file in a subfolder? If so, what would that change/benefit, security-wise?

Posted: Wed Oct 17, 2007 1:43 am
by jmut
security wise...it is good to have all non-web data outside document root...this will include config file with passwords etc.

Posted: Wed Oct 17, 2007 1:49 am
by Kieran Huggins
What I mean is keeping it outside of the web root, for example:

Code: Select all

~/settings.php

~/public_html/
~/public_html/index.html
~/public_html/images/*
...etc...
When you include the file, you'll need to do it like so:

Code: Select all

include($_SERVER['DOCUMENT_ROOT'].'../settings.php')
Does that make sense?

That way no one can access the file with your sensitive config data via an http request.

Posted: Wed Oct 17, 2007 2:00 am
by Josh1billion
Excellent, thanks both of you guys for that information. I have made the changes accordingly, tested, and all is working and secure. :)

Posted: Wed Oct 17, 2007 2:19 am
by jmut
it is never really secure... hooo hooo hoo *madly*

Posted: Wed Oct 17, 2007 2:19 am
by Josh1billion
:lol:

Posted: Wed Oct 17, 2007 3:23 am
by Mordred
This is still a problem if there is a local file include vulnerability on the site. A better, more paranoid solution would be to keep the credentials in the environment, as proposed for example by Chris Shiflett here: http://shiflett.org/articles/shared-hosting

Posted: Wed Oct 17, 2007 3:39 am
by Kieran Huggins
That's totally boss. Nice tip!

It should be noted that you'd need to restart apache for it to work, though.

Posted: Wed Oct 17, 2007 4:01 am
by Josh1billion
Mordred wrote:This is still a problem if there is a local file include vulnerability on the site. A better, more paranoid solution would be to keep the credentials in the environment, as proposed for example by Chris Shiflett here: http://shiflett.org/articles/shared-hosting
Let me first thank you for the information before I comment and ask questions. This advice is very appreciated. :)

After taking a look at that link, let me summarize for anyone browsing the thread for information (correct me if I misunderstood any of it): it sounds like this is a vulnerability found in some shared hosting servers, and it sounds like a typical PHP coder would need specific access to Apache configuration to solve it (something only the host itself has access to), and that this solution could pose a security flaw if you accidentally make the mistake of using a function that outputs data from $_SERVER, including phpinfo(), meaning that you'd have to make sure you absolutely never let any user read the output of phpinfo() or similar functions.

So if you need Apache access to implement this solution, wouldn't it be difficult to do this, requiring you to contact your host and convince them to add your SetEnv directives to the apache configuration (and restart the server so that that the configuration changes are applied), and then go through the whole process every time you change your database username or password and also every time your hosting package is moved to another server? How likely is a typical host to be willing to go through all that trouble? (Dreamhost is the one I'm considering in the long-term, and I hear their support is good.. but I'm using another host until I need the extra bandwidth or until June of 2008 when the account is up)

And if another user on the same hosting server executes phpinfo() (on his own hosting space), or a similar function, will the function have access to the environment variables in your hosting package, or are the environment variables separated?

All in all, I would like to apply this suggestion, but it sounds like it won't be easy, and could be impossible if my host doesn't cooperate.

Posted: Wed Oct 17, 2007 5:38 am
by Benjamin
Any file with login credentials or sensitive data is best kept above the webroot. There are situations where multiple servers behind load balancers can sometimes be configured incorrectly which will lead to raw PHP source code being sent to the browser as plain text. Also, Apache has been known in rare occasions to glitch and not process PHP in certain situations, one of which I believe can happen when a server is overloaded. The optimum solution to prevent security issues is:

1. Place any file with sensitive information above the webroot
2. Use mod_security to ensure outgoing data does not contain raw PHP code
3. Ensure all servers are configured correctly

Facebook failed to adhere to these standards and ended up with the source code to their index page on digg.com.

Posted: Wed Oct 17, 2007 5:46 am
by Josh1billion
Interesting stuff. I never heard about the Facebook thing til now, heh.. I see it's removed now, though.