473,289 Members | 1,839 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,289 software developers and data experts.

how to hide db access?

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?
Aug 22 '08 #1
7 1909
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
==================

Aug 22 '08 #2
On Aug 22, 3:41*pm, Michael Vilain <vil...@NOspamcop.netwrote:
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
Aug 22 '08 #3
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
==================

Aug 23 '08 #4
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
Sep 1 '08 #5
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
==================

Sep 2 '08 #6
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.
Sep 2 '08 #7
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
==================

Sep 2 '08 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
by: genetic.error | last post by:
I'm moving from Vb6 to VB.Net. I have a feeling this has come up before... The VS.Net MSDN file seems to state that the following should work: Form1.Show Form1.Visible = True Form1.Hide...
9
by: Mark | last post by:
Hi All, I am trying to use the function found on the MVP site http://www.mvps.org/access/api/api0019.htm to hide the Access window. I must be missing something as I keep getting an error message:...
1
by: lauren quantrell | last post by:
Before getting pistol whipped, I know this is a well-worn topic but I don't see the answer... I know how to hide the Access window, I know how to disable the Access application's close button, but...
13
by: genetic.error | last post by:
I'm moving from Vb6 to VB.Net. I have a feeling this has come up before... The VS.Net MSDN file seems to state that the following should work: Form1.Show Form1.Visible = True Form1.Hide...
4
by: MLH | last post by:
I copied the code example below from A97 HELP. However, I get an error when I try to use something like frmMainMenu.Hide and am uncertain as to why. Ideas? The following example assumes two...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.