how to hide db access?

[Fred]

I have a file (access.php) with the db username and pwd, which I include in
every php file that needs db access. I'm not clear on how to set the path.

I have an account on a shared *nix server, and this code will be in a
subdomain (which is a subdirectory).

Do I go upward with "../../access.php" or do I start with "/" and figure out
where that actually is, then go downward?

[Jerry Stuckle]

Fred wrote:

I have a file (access.php) with the db username and pwd, which I include in
every php file that needs db access. I'm not clear on how to set the path.

I have an account on a shared *nix server, and this code will be in a
subdomain (which is a subdirectory).

Do I go upward with "../../access.php" or do I start with "/" and figure out
where that actually is, then go downward?

"/" would be the root directory of your server. You can use
$_SERVER['DOCUMENT_ROOT'] to get to the root directory of the web site
then add the subdirectory name (which is dependent on the subdirectory
name should you move to another site, for instance). Or you could use
relative access such as "../../access.php" (which is dependent on the
directory the including file is in).

Neither way is great, but the best you can do with your setup. Pick one
and use it consistently.

Or, use a host which doesn't require subdomains to be in subdirectories
(there's no reason why that needs to be the case) and just use
$_SERVER['DOCUMENT_ROOT'].

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[WalterGR]

On Aug 22, 3:41*pm, Michael Vilain <[e-mail]:

If you want to stop someone more dedicated, don't use a shared host. *
Buy a virtual hosted environment where you are the admin of a virtual
box.

My shared hosting provider uses php-cgiwrap.[1] This causes PHP to
run under your account's credentials. You can then change the
permissions on the file with your database username and password so
that only your account can read the file.

One consequence of this is that your other files are potentially
visible if someone cracks your script, as PHP can then read files that
you have "read" permissions on, even if you have blocked "group" and
"other".

Walter
[1] http://www.pair.com/support/knowledg...p-cgiwrap.html

[Jerry Stuckle]

Michael Vilain wrote:

In article <g8**********@aioe.org>, Fred <Fr**@notspam.notwrote:

>I have a file (access.php) with the db username and pwd, which I include in
every php file that needs db access. I'm not clear on how to set the path.

I have an account on a shared *nix server, and this code will be in a
subdomain (which is a subdirectory).

Do I go upward with "../../access.php" or do I start with "/" and figure out
where that actually is, then go downward?

In most UNIX-based shared hosts, if the web browser can see the file due
to OTHER permissions being set to READ, then potentially all users can
see that file.

Incorrect. PHP can be configured to allow the current virtual host
access to only its files. And ssh/ftp access restrict it at the host level.

If your web host allows unrestricted shell access, anyone access your
file by wandering around the filesystem. If your web host restricts
shell access (e.g. users get a chroot'ed or "jailed" shell that only
sees it's home directory), you should be OK from casual or script-kiddy
hackery.

Any host who does that deserves to go out of business.

If your web host doesn't use a ftp server that allows for jailed access,
the same problem applies. Another user connecting via ftp could change
their directory and wander through the entire filesystem. There are
lots of ftp servers with varying levels of security and accountability.
Ask your web hoster what they use. Or just connect to their ftp server
with a command-line client and see if you can cd to /. If you see the
whole filesystem when you list the directory, that's bad.

Ditto. It's too easy to limit both ssh and ftp access for a hosting
company NOT to do it. If I found my host did, I'd be gone in a couple
of nanoseconds.

To answer your question specifically, I read an article some time ago by
a php developer that offered a very elegant solution to this problem.
He talks specifically about your problem:

http://shiflett.org/articles/shared-hosting

Essentially, his idea is to include a protected file with SetEnv
directives in the Apache startup script that define variables to set the
MySQL database and password. The Apache startup script is run as root,
so you can put the included script with the directives in your home
directory outside your web server's DocumentRoot. And you can protect
it from being read by anyone but you. If you hardcode the mcrypt'ed
database name (to be unscrambled by the code) and you store the
mcrypt'ed password in the Apache's global variable array, you can use
$_SERVER{"someobscurereference"} to retrieve the cyphertext and decrypt
the password.

Which is over 4 years old and COMPLETELY out of date. It wasn't even
current when it was written.

This won't stop someone else on the system from using phpinfo() to dump
the $_SERVER array, dumping your code, wandering through it to see how
to access your database, and gaining access to your database and
password. It will stop the casual hacker.

phpinfo() doesn't have that information. And they would have to be able
to put the file in your directory, which is impossible with proper security.

If you want to stop someone more dedicated, don't use a shared host.
Buy a virtual hosted environment where you are the admin of a virtual
box. You have to know how to admin such an enviroment or have someone
who can admin it for you. But it's harder to break into that sort of
environment.

Shared hosts are quite secure, if they are set up properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[RJ_32]

WalterGR wrote:

My shared hosting provider uses php-cgiwrap.[1] This causes PHP to
run under your account's credentials. You can then change the
permissions on the file with your database username and password so
that only your account can read the file.

my shared hosting uses FastCGI which also runs under my account (not as the
nobody account) so that's the same.

If I set perms to 400 as you say, then does this scheme provide JUST AS GOOD
protection as if I were to move the file (that has username and pwd in it) up
and out of the public_html hierarchy?

It's on a jail shell.
ALSO, how would anybody get at the info in the "access_php" file anyway? Let's
say that no steps are take to safeguard the database access info, like so:

access.php file in webroot:
<?php
$user = "username";
$pwd = "password";
?>

index.php file in webroot:
<?php
require "access.php";
mysql_connect('localhost', $user, $pwd) or die(mysql_error());
?>
Anybody can request access.php via their browser but they would get zero
output. How would anybody get at the db info?

>
One consequence of this is that your other files are potentially
visible if someone cracks your script, as PHP can then read files that
you have "read" permissions on, even if you have blocked "group" and
"other".

Walter
[1] http://www.pair.com/support/knowledg...p-cgiwrap.html

[Jerry Stuckle]

RJ_32 wrote:

WalterGR wrote:

>My shared hosting provider uses php-cgiwrap.[1] This causes PHP to
run under your account's credentials. You can then change the
permissions on the file with your database username and password so
that only your account can read the file.

my shared hosting uses FastCGI which also runs under my account (not as the
nobody account) so that's the same.

If I set perms to 400 as you say, then does this scheme provide JUST AS GOOD
protection as if I were to move the file (that has username and pwd in it) up
and out of the public_html hierarchy?

It's on a jail shell.
ALSO, how would anybody get at the info in the "access_php" file anyway? Let's
say that no steps are take to safeguard the database access info, like so:

access.php file in webroot:
<?php
$user = "username";
$pwd = "password";
?>

index.php file in webroot:
<?php
require "access.php";
mysql_connect('localhost', $user, $pwd) or die(mysql_error());
?>
Anybody can request access.php via their browser but they would get zero
output. How would anybody get at the db info?

>One consequence of this is that your other files are potentially
visible if someone cracks your script, as PHP can then read files that
you have "read" permissions on, even if you have blocked "group" and
"other".

Walter
[1] http://www.pair.com/support/knowledg...p-cgiwrap.html

What you have to worry about is not when things work correctly. It's
when there is a problem and things work incorrectly.

What if, for instance, due to a glitch in your web server, it suddenly
stopped parsing .php files for a short time? All of your code is now
visible.

But more than that - just fetching the page gives a 200 OK response -
which will tell a hacker the file exists - and perhaps he can make use
of that information. Storing it outside of the web server's root does
not allow even that much access.

The safest way to prohibit access to files is to not store them in the
document root.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[RJ_32]

Jerry Stuckle wrote:

What you have to worry about is not when things work correctly. It's
when there is a problem and things work incorrectly.

What if, for instance, due to a glitch in your web server, it suddenly
stopped parsing .php files for a short time? All of your code is now
visible.

I actually did see that happen to someone once, about a year ago. That's what
makes me interested in the topic.

>
But more than that - just fetching the page gives a 200 OK response -
which will tell a hacker the file exists - and perhaps he can make use
of that information. Storing it outside of the web server's root does
not allow even that much access.

The safest way to prohibit access to files is to not store them in the
document root.

which would mean moving all of them, except those that contain includes.

[Jerry Stuckle]

RJ_32 wrote:

Jerry Stuckle wrote:

>What you have to worry about is not when things work correctly. It's
when there is a problem and things work incorrectly.

What if, for instance, due to a glitch in your web server, it suddenly
stopped parsing .php files for a short time? All of your code is now
visible.

I actually did see that happen to someone once, about a year ago. That's what
makes me interested in the topic.

>But more than that - just fetching the page gives a 200 OK response -
which will tell a hacker the file exists - and perhaps he can make use
of that information. Storing it outside of the web server's root does
not allow even that much access.

The safest way to prohibit access to files is to not store them in the
document root.

which would mean moving all of them, except those that contain includes.

All of them which are not directly accessible as web pages, anyway.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================