Database password security

[SmartBloke]

Why is it advisable to place scripts which contain details of your
login and password outside of the publicly accessible web area on your
server.
Surely if the files that contain the details are given a php extension
then no-one can get at the information contained by these files even
if they point their browsers directly at the correct named file,
because apache will parse the php file before it is sent.

i.e.

if the file is called options.php and it resides in the web root
directory and contains the following ;-

<?php

define('DBUSER' , 'Username') ;
define('DBPASS' , 'Password123') ;

?>

If a web user points their browser directly at this page they will
just get a blank page - is there another way of gaining access to the
contents of this file that I am overlooking ?

tia
smartbloke

[Jasper Bryant-Greene]

Re: Database password security

SmartBloke wrote:
[color=blue]
> Surely if the files that contain the details are given a php extension
> then no-one can get at the information contained by these files even
> if they point their browsers directly at the correct named file,
> because apache will parse the php file before it is sent.[/color]

During an upgrade a sysadmin, or you, on your server accidentally
forgets to put the LoadModule directive in apache.conf, say for an hour
or so.

During that hour any visitors to your website are treated with the
source code to your page, including all database schema information,
passwords, etc.

Even if it's only 5 minutes, at least one person is bound to see the
sensitive information. It's just safer to keep it out of the publicly
accessible directories.

--
Jasper Bryant-Greene
Cabbage Promotions

[Michael Fesser]

Re: Database password security

.oO(SmartBloke)
[color=blue]
>Why is it advisable to place scripts which contain details of your
>login and password outside of the publicly accessible web area on your
>server.[/color]

It's advisable to put _all_ scripts outside the document root:

* No one is able to call them from the outside.
* No one is able to call scripts out of context, which may lead to
strange results and error messages.
* You don't have to worry about filename extensions, don't have to use
.php all the time.
[color=blue]
>Surely if the files that contain the details are given a php extension
>then no-one can get at the information contained by these files even
>if they point their browsers directly at the correct named file,
>because apache will parse the php file before it is sent.[/color]

I wouldn't be too sure about that. It's always possible that the server
"forgets" to parse a file (configuration error, maintenance, ...).

Micha

[Tim Van Wassenhove]

Re: Database password security

In article <e67rj050b20h7q cusu3535of0eajj 131gc@4ax.com>, Michael Fesser wrote:[color=blue]
> .oO(SmartBloke)
>[color=green]
>>Why is it advisable to place scripts which contain details of your
>>login and password outside of the publicly accessible web area on your
>>server.[/color][/color]
[color=blue]
> It's advisable to put _all_ scripts outside the document root:[/color]

No it's not. Allthough i see reasons not to put files containing
credentials in a public area.

[color=blue]
> * No one is able to call them from the outside.[/color]

If it was impossible or unwanted to call scripts from the outside, why
would there be scripts in the first place? Because we want people to
call some scripts. (And those we don't want them to call, we should not
make public)

[color=blue]
> * No one is able to call scripts out of context, which may lead to
> strange results and error messages.[/color]

Actually, this depends totally on how the scripts are designed. If they
are well-designed, they will know when they are expected to be executed
(and when they should dispatch controll to another script).

But there is no relationship between knowledge about their context, and
the place where they are (public vs non-public area)

[color=blue]
> * You don't have to worry about filename extensions, don't have to use
> .php all the time.[/color]

Again, this is true for both public as non-public areas. And thus not a
good reason to put them outside the public area.



--
Tim Van Wassenhove <http://home.mysth.be/~timvw>

[Michael Fesser]

Re: Database password security

.oO(Tim Van Wassenhove)
[color=blue][color=green]
>> * No one is able to call them from the outside.[/color]
>
>If it was impossible or unwanted to call scripts from the outside, why
>would there be scripts in the first place?[/color]

I was referring to scripts performing backend tasks, initialization,
database queries, form processing, calculations etc., in other words all
the "applicatio n logic" or whatever you like to call it. Of course the
scripts representing webpages have to be accessible.
[color=blue][color=green]
>> * No one is able to call scripts out of context, which may lead to
>> strange results and error messages.[/color]
>
>Actually, this depends totally on how the scripts are designed. If they
>are well-designed, they will know when they are expected to be executed
>(and when they should dispatch controll to another script).[/color]

Do you know for all of your scripts how they will react if they are
called directly? Even if you put everything in classes and functions,
there may still be unresolved dependencies because the script was not
called from within another it depends upon. I have many scripts that
call methods of a global application object. If this object is not
available it'll rain error messages. I avoid such trouble with simply
making them not available to the public. All application and library
stuff is outside the document root.
[color=blue][color=green]
>> * You don't have to worry about filename extensions, don't have to use
>> .php all the time.[/color]
>
>Again, this is true for both public as non-public areas. And thus not a
>good reason to put them outside the public area.[/color]

An often heard "security" argument is to give scripts the extension .php
so the server would always parse them (.inc files would be delivered as
plain text for example in most cases). Outside the document root the
filename simply doesn't matter, because it's out of reach of the
webserver and the PHP interpreter doesn't care about filenames.

Micha

[Tim Van Wassenhove]

Re: Database password security

In article <4phrj01lm4t9m1 l69dhr4sh1ih57j cf1kf@4ax.com>, Michael Fesser wrote:[color=blue]
> .oO(Tim Van Wassenhove)
>[color=green][color=darkred]
>>> * No one is able to call them from the outside.[/color]
>>
>>If it was impossible or unwanted to call scripts from the outside, why
>>would there be scripts in the first place?[/color]
>
> I was referring to scripts performing backend tasks, initialization,
> database queries, form processing, calculations etc., in other words all
> the "applicatio n logic" or whatever you like to call it. Of course the
> scripts representing webpages have to be accessible.[/color]

Although you cutted it away, you said and i quote:
It's advisable to put _all_ scripts outside the document root:

That made me think you were not only referring to scripts performing backend
tasks...
[color=blue][color=green][color=darkred]
>>> * No one is able to call scripts out of context, which may lead to
>>> strange results and error messages.[/color]
>>
>>Actually, this depends totally on how the scripts are designed. If they
>>are well-designed, they will know when they are expected to be executed
>>(and when they should dispatch controll to another script).[/color]
>
> Do you know for all of your scripts how they will react if they are
> called directly? Even if you put everything in classes and functions,
> there may still be unresolved dependencies because the script was not
> called from within another it depends upon. I have many scripts that
> call methods of a global application object. If this object is not
> available it'll rain error messages. I avoid such trouble with simply
> making them not available to the public.[/color]

Here i think you're just handling the unwanted results and not the causes.

If the script is designed well, it can detect if it's expected to run.
And it can perform data validation. And it can redirect the user to the
right script (Or at least die and log the error) instead of thrashing the database.

[color=blue]
> All application and library
> stuff is outside the document root.[/color]

I agree :)
[color=blue][color=green][color=darkred]
>>> * You don't have to worry about filename extensions, don't have to use
>>> .php all the time.[/color]
>>
>>Again, this is true for both public as non-public areas. And thus not a
>>good reason to put them outside the public area.[/color]
>
> An often heard "security" argument is to give scripts the extension .php
> so the server would always parse them
>(.inc files would be delivered as
> plain text for example in most cases).[/color]

There are more things that i hear often, although i not agree with them.

Imho a file that contains credentials, should not be in a public place.
It doesn't even matter if it's name ends with .php and is likely to be
interpreted by PHP before being shown. Blame it on Murphy :)

--
Tim Van Wassenhove <http://home.mysth.be/~timvw>

[Michael Fesser]

Re: Database password security

.oO(Tim Van Wassenhove)
[color=blue]
>Although you cutted it away, you said and i quote:
>It's advisable to put _all_ scripts outside the document root:
>
>That made me think you were not only referring to scripts performing backend
>tasks...[/color]

Yep, my fault, was misleading. Sorry.
[color=blue]
>Here i think you're just handling the unwanted results and not the causes.
>
>If the script is designed well, it can detect if it's expected to run.
>And it can perform data validation. And it can redirect the user to the
>right script (Or at least die and log the error) instead of thrashing the database.[/color]

I'm talking about the backend. ;)

The scripts (class definitions for example) don't know anyhing about
webpages, users or whatever. They are just used and instantiated from
within other scripts, but they have to be sure that some other scripts
or objects they rely on are already loaded or instantiated. It wouldn't
make sense to implement some detection mechanismn to avoid direct calls
in this case, the overhead and performance hit would be too heavy I
think (and I can't think of an easy way to do it at the moment).
[color=blue]
>Imho a file that contains credentials, should not be in a public place.
>It doesn't even matter if it's name ends with .php and is likely to be
>interpreted by PHP before being shown. Blame it on Murphy :)[/color]

ACK

The more important the file content is, the more likely the server will
fail and not only show the file in plain text to all visitors, but also
replace all pages on that site with the confidential file to reach the
maximum audience and mail it to AOL ... SCNR

Micha

[JV]

Re: Database password security

Please forgive me for sounding like a noob about this, but I kinda am new to
apache w/ php mod.
"Michael Fesser" <netizen@gmx.ne t> wrote in message
news:e67rj050b2 0h7qcusu3535of0 eajj131gc@4ax.c om..
<snip>[color=blue]
> It's advisable to put _all_ scripts outside the document root:[/color]
<snip>

where is a safe place to put such script files that the apache server is
still capable of accessing them?

and how do u include the files if they are outside the document root scope ?

JV

[Chung Leong]

Re: Database password security

"SmartBloke " <smartbloke@mai l.com> wrote in message
news:e997b874.0 409070211.3d464 e86@posting.goo gle.com...[color=blue]
> Why is it advisable to place scripts which contain details of your
> login and password outside of the publicly accessible web area on your
> server.[/color]

It's largely pointless from a practical point of view. The database
login/password doesn't buy your much, since databases are rarely set up to
accept connect from anywhere.

It's the kind of things that people who think they know security (but really
do not) do.

[Tony Marston]

Re: Database password security


"JV" <jveil.hotpop@c om> wrote in message
news:spt%c.1448 14$Fg5.63485@at tbi_s53...[color=blue]
> Please forgive me for sounding like a noob about this, but I kinda am new
> to
> apache w/ php mod.
> "Michael Fesser" <netizen@gmx.ne t> wrote in message
> news:e67rj050b2 0h7qcusu3535of0 eajj131gc@4ax.c om..
> <snip>[color=green]
>> It's advisable to put _all_ scripts outside the document root:[/color]
> <snip>
>
> where is a safe place to put such script files that the apache server is
> still capable of accessing them?
>
> and how do u include the files if they are outside the document root scope
> ?
>
> JV[/color]

Via the include_path directive in the php.ini file. In my case I have a
directory called "includes" which is outside the document root, therefore
inaccessible from any URL. When a script contains include('filena me.inc')
PHP will first look in the current working directory. If the file exists
there it will be used from there. If it does not exist there then PHP will
look in each of the directories specified on the include_path directive
until it gets a hit. Simple, isn't it?

If you do not have access to the php.ini file then you can modify the
include_path directive in any of the following ways:

(a) If your web server is Apache you can create a .htaccess file containing
the following:

php_value include_path "...."

Note that the format of the string varies between Windows and Unix.

(b) Within a PHP script you can use the ini_set() function to supply a new
value for include_path.

Hope this helps.

--
Tony Marston

http://www.tonymarston.net

[Michael Fesser]

Re: Database password security

.oO(JV)
[color=blue]
>"Michael Fesser" <netizen@gmx.ne t> wrote in message
>news:e67rj050b 20h7qcusu3535of 0eajj131gc@4ax. com..
><snip>[color=green]
>> It's advisable to put _all_ scripts outside the document root:[/color]
><snip>
>
>where is a safe place to put such script files that the apache server is
>still capable of accessing them?[/color]

My "all" was misleading, I was referring to scripts that are not meant
to be called directly in a browser (the "applicatio n logic").
[color=blue]
>and how do u include the files if they are outside the document root scope ?[/color]

PHP doesn't care about the webserver's document root, it accesses and
includes the files directly through the filesystem.

Micha