By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,078 Members | 2,159 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,078 IT Pros & Developers. It's quick & easy.

My rant about unix home directories

P: n/a
Hello Newsgroup:

This is my little rant about security and why we have home directories.

You may choose to ignore it or disagree with it, that is your perogative
and I won't care, but... this little rant needs to be said in the 21'st
century, as we seem to have forgotten about it.

Many PHP packages and cgi scripts ask you to store database settings
and passwords in web space.

Of course, it's secure, so long as configuration files are given
a [.php|.cgi] extension, right?

Wrong.

I think most of us have seen misconfigured web servers that send the
contents of PHP files rather then running them through an interpreter
at some point. A .php extension does not give a configuration file
security. I've seen this happen many times as I'm sure anyone here has.

Time was, all the CGI programming FAQ's would warn you about this, they would
tell you, always make sure passwords and critical pieces of information are
kept safely outside web space. This "old timer" advice still applies.

The general rule was, if you don't want it sent to the browser, don't put it on
the web server. (meaning, in "web space")

Don't protect something with an .htaccess file.

Don't protect something with a .php|.cgi or .whatever

Just don't put critical bits of data on the web server. (unless you
have no choice)

But.. not any more, we've forgotten this ancient advice.

We now routinely ask people to edit some sort of .php file for database
settings and save it in the same directory as the script running it. It's
common practice, heck I've done it a few times.... From what I gather,
PHP's so called "safe mode" (isn't that a kick in the teeth) demands
you do this.

It's convenient, it's what users have come to expect.

But... it is not secure.

We have home directories for this sort of thing and just I wish we'd get back
to the old practice of using them for their intended purpose before ISP's start
making a persons home directory the same as the web directory.

There. rant over. Sorry.. had to say it, I don't expect anyone to actually
listen to it or anything, people seldom do.

You may go back to storing all your critical database settings in web space
now. :-)

Jamie
--
http://www.geniegate.com Custom web programming
gu******@lnubb.pbz (rot13) User Management Solutions
Apr 29 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Jamie wrote:
Hello Newsgroup:

This is my little rant about security and why we have home directories.

You may choose to ignore it or disagree with it, that is your perogative
and I won't care, but... this little rant needs to be said in the 21'st
century, as we seem to have forgotten about it.

Many PHP packages and cgi scripts ask you to store database settings
and passwords in web space.

Of course, it's secure, so long as configuration files are given
a [.php|.cgi] extension, right?

Wrong.

I think most of us have seen misconfigured web servers that send the
contents of PHP files rather then running them through an interpreter
at some point. A .php extension does not give a configuration file
security. I've seen this happen many times as I'm sure anyone here has.

Time was, all the CGI programming FAQ's would warn you about this, they would
tell you, always make sure passwords and critical pieces of information are
kept safely outside web space. This "old timer" advice still applies.

The general rule was, if you don't want it sent to the browser, don't put it on
the web server. (meaning, in "web space")

Don't protect something with an .htaccess file.

Don't protect something with a .php|.cgi or .whatever

Just don't put critical bits of data on the web server. (unless you
have no choice)

But.. not any more, we've forgotten this ancient advice.

We now routinely ask people to edit some sort of .php file for database
settings and save it in the same directory as the script running it. It's
common practice, heck I've done it a few times.... From what I gather,
PHP's so called "safe mode" (isn't that a kick in the teeth) demands
you do this.

It's convenient, it's what users have come to expect.

But... it is not secure.

We have home directories for this sort of thing and just I wish we'd get back
to the old practice of using them for their intended purpose before ISP's start
making a persons home directory the same as the web directory.

There. rant over. Sorry.. had to say it, I don't expect anyone to actually
listen to it or anything, people seldom do.

You may go back to storing all your critical database settings in web space
now. :-)

Jamie


Three thoughts occurred to me when reading this:
1. How is this specific to Unix and/or home directories? It seems more
about keeping private data in the web server space.
2. Why not keep most of your private data in a database? That is not
within the web server space but can be accessed as needed.
3. If you need to store private data within the web server space, why
not encrypt it first?

-david-

Apr 29 '06 #2

P: n/a
> Many PHP packages and cgi scripts ask you to store database settings
and passwords in web space.
I did not encounter them. And if you DO encounter them, you can always
let those pages call a script outside the web root. And off course you
should. The web root is PUBLIC space. So, anything you put in there is
publicly available. Things that should not be publicly available should
be kept out of there. Period.

Of course, it's secure, so long as configuration files are given
a [.php|.cgi] extension, right?

Wrong. Wrong indeed. Alas there are ways for a hacker to get to the source
sometimes.
I think most of us have seen misconfigured web servers that send the
contents of PHP files rather then running them through an interpreter
at some point. A .php extension does not give a configuration file
security. I've seen this happen many times as I'm sure anyone here has.

Time was, all the CGI programming FAQ's would warn you about this, they would
tell you, always make sure passwords and critical pieces of information are
kept safely outside web space. This "old timer" advice still applies.

The general rule was, if you don't want it sent to the browser, don't put it on
the web server. (meaning, in "web space")

Don't protect something with an .htaccess file.

Don't protect something with a .php|.cgi or .whatever

Just don't put critical bits of data on the web server. (unless you
have no choice)

But.. not any more, we've forgotten this ancient advice.

We now routinely ask people to edit some sort of .php file for database
settings and save it in the same directory as the script running it. It's
common practice, heck I've done it a few times.... From what I gather,
PHP's so called "safe mode" (isn't that a kick in the teeth) demands
you do this.

It's convenient, it's what users have come to expect.

But... it is not secure.

We have home directories for this sort of thing and just I wish we'd get back
to the old practice of using them for their intended purpose before ISP's start
making a persons home directory the same as the web directory.

There. rant over. Sorry.. had to say it, I don't expect anyone to actually
listen to it or anything, people seldom do.

You may go back to storing all your critical database settings in web space
now. :-)


My web root still has some settings.php. I had to, as my development
environment and my provider's environment differ too much. Off course,
all it does it correct the right settings that it digs up from a deeper,
"require"d file outside the web space (both live and on development).

Thanks for the warning. Take a glass of water, cool down from your rant
and have a nice weekend.

Apr 29 '06 #3

P: n/a
>1. How is this specific to Unix and/or home directories? It seems more

It isn't, except that some other setups don't have an obvious
place equivalent to a home directory.
about keeping private data in the web server space.
2. Why not keep most of your private data in a database? That is not
within the web server space but can be accessed as needed.
Because one of the most important pieces of private data is the
password to the database, which obviously can't be kept in
the database.
3. If you need to store private data within the web server space, why
not encrypt it first?


So where do you keep the key to it?

Gordon L. Burditt
Apr 29 '06 #4

P: n/a
Pointless rant. In a typical set up the database server isn't
accessible to the outside world, so the risk of exposure through a
misconfigured web server isn't that unreasonable to take. The database
login/password is only useful to someone who can access the
database--i.e. another account on the same server. Putting your config
file your home directory does not prevent him from reading it.

Ideally any sensitive info should be stored in httpd.conf, readable
only by root.

Apr 29 '06 #5

P: n/a
In article <Lc1146303849229750x9dadb4@localhost>,
no****@geniegate.com (Jamie) wrote:
<deletia>


I store all my db/passwd settings outside web server scope and require
them into my php scripts. You can't surf to these files.

BUt I was hacked nonetheless! Fact is that my community system allowed
for files to be uploaded to the web server through users galleries,
web forums and such - and I didn't have a check if the file uploaded
was a PHP file. So one person uploaded a .php file as an "image" in
his gallery (so there never was any doubt who did it).

Then he surfed to this php file as he would have surfed to his image.
Only, it wasn't an image, it was a PHP script that listed files on the
hard drive, or posted the content of them.

Luckily, the web server process doesn't have read access to anything
outside it's web server account, but it - obviously - has access to
these files outside of the document root, which he of course could
read, and did - and thus had complete access to my entire database
(through their custom php files, not through remote access to MySQL).
So he would upload custom php files that did all sort of things with
my databases. Luckily, his motive was not wreck havoc and did more or
less benign - although very irritating - things like changing
everyones account picture and so on.

I pressed charges, of course. Turns out he was a fifteen year old kid
and his parents got scared shitless. Hopefully he's learned a lesson.
The police didn't do anything more since I didn't want to take it any
further than to use them as intimidation.

--
Sandman[.net]
Apr 29 '06 #6

P: n/a
In article <ks***************@fe05.usenetserver.com>,
David Haynes <da***********@sympatico.ca> wrote:
1. How is this specific to Unix and/or home directories? It seems more
about keeping private data in the web server space.
Indeed.
2. Why not keep most of your private data in a database? That is not
within the web server space but can be accessed as needed.
Well, information about how to connect to the database and
username/password couldn't really be kept in the database you're
trying to connect to.
3. If you need to store private data within the web server space, why
not encrypt it first?


The OP was probably mostly talking about "download your PHP guestbook
now" type of scripts, where the scripts has its settings in a file
that needs to be resided on the same path as the script itself, for
convenience - since the programmer, or program, doesn't know where
"Outside the web scope is" for all the people that will download the
script.

Encrypting such a file needs the user to know HOW to encrypt it. A
startup process that asks - via web forms - for the passwd/user and
then saves and reades them encrypted would be a good idea.-

--
Sandman[.net]
Apr 29 '06 #7

P: n/a
In article <11**********************@g10g2000cwb.googlegroups .com>,
"Chung Leong" <ch***********@hotmail.com> wrote:
Pointless rant. In a typical set up the database server isn't
accessible to the outside world, so the risk of exposure through a
misconfigured web server isn't that unreasonable to take. The database
login/password is only useful to someone who can access the
database--i.e. another account on the same server. Putting your config
file your home directory does not prevent him from reading it.


See another one of my posts in my thread here, where this actually
happened. A user gained access to my MySQL server through a
user/passwd file kept outside the web scope, using the web servers
granted connection to the database. :)
--
Sandman[.net]
Apr 29 '06 #8

P: n/a
In <11**********************@g10g2000cwb.googlegroups .com>,
"Chung Leong" <ch***********@hotmail.com> mentions:
Pointless rant. In a typical set up the database server isn't
accessible to the outside world, so the risk of exposure through a
misconfigured web server isn't that unreasonable to take. The database
login/password is only useful to someone who can access the
database--i.e. another account on the same server. Putting your config
file your home directory does not prevent him from reading it.

Ideally any sensitive info should be stored in httpd.conf, readable
only by root.


I disagree.

If you don't intend to serve something through a web server, it shouldn't be in
web space.

Granted, I think all of us have at some point or another done it
just because it's convenient. For example, I'll sometimes store
library code in web space. It's easier. (and definately makes backups
easier)

The safest way to keep someone from accessing data that maybe you
didn't intend to be accessed is to keep it out of web space. (I say
safest, it's still not fool proof, if the machine itself is compromized
all bets are off.)

Reason this bugs me so much is that people have come to expect such
settings ARE stored on the web server. It's become such common
practice I wish it would stop.

Jamie
--
http://www.geniegate.com Custom web programming
gu******@lnubb.pbz (rot13) User Management Solutions
May 1 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.