permissions and script 'visibility'

[Dave Schwimmer]

I am relatively new to PHP. One of the things that seems glaring obvious
to me (coming from a C/C++ background) is how 'open' everything seems -
(AFAIK). For instance, URLs typically have the name of the php script
that they are calling - also just viewing the source of most web pages
will show you in glorious detail, the paths and names to any PHP scripts
they may be using.

If one was to implement user authorisation (or any other module whose
logic needs to be kept private) in a PHP module (apart from encypting
the script - which has its own pitfalls) -it makes no sense in having
such a module (script or set of scripts) plainly visible/accesible to
the user - who can inspect your user authentication etc at leisure,
whilst sipping his favourite beverage. What is the way to keep your
script inacesible to users so that they cannot simply FTP or GET your
script - giving that the path and file name has been kindly provided?

I think I remember reading somewhere that this is to do with setting
file permissions - for example placing the scripts in afolder above the
web server doc root. But this begs the question that if the user has no
permision to the folder where the php files are kept - how can he
execute them. Actually, the last sentence made me realise that the way
around this (may?) be to have Apache run as a different user from the
web client. Am I correct in this assumption?. Suggestions welcome.

[Gordon Burditt]

Re: permissions and script 'visibility'

>I am relatively new to PHP. One of the things that seems glaring obvious[color=blue]
>to me (coming from a C/C++ background) is how 'open' everything seems -
>(AFAIK). For instance, URLs typically have the name of the php script
>that they are calling - also just viewing the source of most web pages
>will show you in glorious detail, the paths and names to any PHP scripts
>they may be using.[/color]

HTML is visible. PHP code isn't visible via HTTP.
[color=blue]
>If one was to implement user authorisation (or any other module whose
>logic needs to be kept private)[/color]

If the *logic* needs to be kept private, it's probably a
security hole.
[color=blue]
>in a PHP module (apart from encypting
>the script - which has its own pitfalls) -it makes no sense in having
>such a module (script or set of scripts) plainly visible/accesible to
>the user - who can inspect your user authentication etc at leisure,[/color]

If you're talking about a remote user with a web browser, they
*cannot* inspect your PHP code at their leisure.
[color=blue]
>whilst sipping his favourite beverage. What is the way to keep your
>script inacesible to users so that they cannot simply FTP or GET your
>script - giving that the path and file name has been kindly provided?[/color]

Ensure that you provide *NO* path where a user can simply GET your
protected files without authenticating. This is typically done
with a PHP page which checks the user's authentication, and if it's
OK, outputs a Content-type: header, then does a fpassthru() using
a file name *outside the document tree*.
[color=blue]
>I think I remember reading somewhere that this is to do with setting
>file permissions - for example placing the scripts in afolder above the
>web server doc root. But this begs the question that if the user has no
>permision to the folder where the php files are kept - how can he
>execute them. Actually, the last sentence made me realise that the way
>around this (may?) be to have Apache run as a different user from the
>web client. Am I correct in this assumption?. Suggestions welcome.[/color]

If you are attempting to protect against someone who is sharing access
to the same server as you are, you're probably screwed.

Gordon L. Burditt

[samudasu]

Re: permissions and script 'visibility'

To start off with, opening a php file won't show you php code. It only
shows the results of the php script after it's run. ftp should be
password protected, no one but you will have this password.

I've found that placing sensetive files above document_root works
nicely like you've mentioned. Here's how it's done:
/usr/local/apache/htdocs/ is the doc root.
Make a /usr/local/apache/incfiles/ dir to keep sensitive files, db
connect srcipts, user/pass info, etc. Users have no direct access to
these files since they're not in the doc root. Files in this dir are
used with the include() or require() functions. Users don't need
permission to this folder so there are no special permissions required.
The apache user (usually nobody) will access the files.

example:
/usr/local/apache/htdocs/verifylogin.php is a page you can guess what
it does.
I want to include() the script
"/usr/local/apache/incfiles/chkpass.inc.php " in verifylogin.php that
connects to the db and check the clients username password.

verifylogin.php ...

<?php
include'../incfiles/chkpass.inc.php ';
?>
<html>
<body>
<?php
if user/pass correct
show this
if user/pass failed
show this
?>
</body>
</html>

If you view source of verifylogin.php you'll see no php code and no
path / reference to /usr/local/apache/incfiles/chkpass.inc.php .

[Dave Schwimmer]

Re: permissions and script 'visibility'



Gordon Burditt wrote:
[color=blue][color=green]
>>I am relatively new to PHP. One of the things that seems glaring obvious
>>to me (coming from a C/C++ background) is how 'open' everything seems -
>>(AFAIK). For instance, URLs typically have the name of the php script
>>that they are calling - also just viewing the source of most web pages
>>will show you in glorious detail, the paths and names to any PHP scripts
>>they may be using.[/color]
>
>
> HTML is visible. PHP code isn't visible via HTTP.[/color]

WRONG !. It is EXACTLY this kind of laid back approach to security (and
programming in general) that lets me worry about scripters and scripting
languages. I have been playing around with PHP in just 2 days, I see an
obvious security 'hole' and you casually tell me that PHP code isn't
visible via PHP - well try this for size:

type this at your shell/command prompt and see what you get back:

GET http://yourhostname/notsecure.php HTTP/1.1
[color=blue]
>
>[color=green]
>>If one was to implement user authorisation (or any other module whose
>>logic needs to be kept private)[/color]
>
>
> If the *logic* needs to be kept private, it's probably a
> security hole.
>[/color]

wtf are you talking about?. Why would you want the whole world to know
how you authenticate users (you may just as well publish all your
usernames/passwords onto the internet if you're that lax about security).

[color=blue]
>[color=green]
>>in a PHP module (apart from encypting
>>the script - which has its own pitfalls) -it makes no sense in having
>>such a module (script or set of scripts) plainly visible/accesible to
>>the user - who can inspect your user authentication etc at leisure,[/color]
>
>
> If you're talking about a remote user with a web browser, they
> *cannot* inspect your PHP code at their leisure.
>[/color]
Really ?. See my response to your first answer.[color=blue]
>[color=green]
>>whilst sipping his favourite beverage. What is the way to keep your
>>script inacesible to users so that they cannot simply FTP or GET your
>>script - giving that the path and file name has been kindly provided?[/color]
>
>
> Ensure that you provide *NO* path where a user can simply GET your
> protected files without authenticating. This is typically done
> with a PHP page which checks the user's authentication, and if it's
> OK, outputs a Content-type: header, then does a fpassthru() using
> a file name *outside the document tree*.
>[/color]
This seems more like it. But it skirts around the issue. Where do you
keep the PHP which ckecks the user's authentication? (this was precisely
my question in the first place).[color=blue]
>[color=green]
>>I think I remember reading somewhere that this is to do with setting
>>file permissions - for example placing the scripts in afolder above the
>>web server doc root. But this begs the question that if the user has no
>>permision to the folder where the php files are kept - how can he
>>execute them. Actually, the last sentence made me realise that the way
>>around this (may?) be to have Apache run as a different user from the
>>web client. Am I correct in this assumption?. Suggestions welcome.[/color]
>
>
> If you are attempting to protect against someone who is sharing access
> to the same server as you are, you're probably screwed.[/color]

True, but its a no brainer to solve that one (just use a dedicated server).[color=blue]
>
> Gordon L. Burditt[/color]

[Dave Schwimmer]

Re: permissions and script 'visibility'



samudasu wrote:
[color=blue]
> To start off with, opening a php file won't show you php code. It only
> shows the results of the php script after it's run. ftp should be
> password protected, no one but you will have this password.
>
> I've found that placing sensetive files above document_root works
> nicely like you've mentioned. Here's how it's done:
> /usr/local/apache/htdocs/ is the doc root.
> Make a /usr/local/apache/incfiles/ dir to keep sensitive files, db
> connect srcipts, user/pass info, etc. Users have no direct access to
> these files since they're not in the doc root. Files in this dir are
> used with the include() or require() functions. Users don't need
> permission to this folder so there are no special permissions required.
> The apache user (usually nobody) will access the files.
>
> example:
> /usr/local/apache/htdocs/verifylogin.php is a page you can guess what
> it does.
> I want to include() the script
> "/usr/local/apache/incfiles/chkpass.inc.php " in verifylogin.php that
> connects to the db and check the clients username password.
>
> verifylogin.php ...
>
> <?php
> include'../incfiles/chkpass.inc.php ';
> ?>
> <html>
> <body>
> <?php
> if user/pass correct
> show this
> if user/pass failed
> show this
> ?>
> </body>
> </html>
>
> If you view source of verifylogin.php you'll see no php code and no
> path / reference to /usr/local/apache/incfiles/chkpass.inc.php .
>[/color]

Thank you. This is PRECISELY the sort of information I was looking for.

[Gordon Burditt]

Re: permissions and script 'visibility'

>>>I am relatively new to PHP. One of the things that seems glaring obvious[color=blue][color=green][color=darkred]
>>>to me (coming from a C/C++ background) is how 'open' everything seems -
>>>(AFAIK). For instance, URLs typically have the name of the php script
>>>that they are calling - also just viewing the source of most web pages
>>>will show you in glorious detail, the paths and names to any PHP scripts
>>>they may be using.[/color]
>>
>>
>> HTML is visible. PHP code isn't visible via HTTP.[/color]
>
>WRONG !. It is EXACTLY this kind of laid back approach to security (and
>programming in general) that lets me worry about scripters and scripting
>languages. I have been playing around with PHP in just 2 days, I see an
>obvious security 'hole' and you casually tell me that PHP code isn't
>visible via PHP - well try this for size:
>
>type this at your shell/command prompt and see what you get back:
>
>GET http://yourhostname/notsecure.php HTTP/1.1[/color]

If I put this file on my server:
<HTML>
<HEAD>
</HEAD>
<BODY>
<?php
if ($_GET['password'] == 'george') {
echo 'Secret stuff';
} else {
echo 'Password incorrect. Go away.';
}
?>
</BODY>
</HTML>

and then I call it with http://myserver.com/notsecure.php?password=george
I get:

<HTML>
<HEAD>
</HEAD>
<BODY>
Secret stuff</BODY>
</HTML>

and if I call it with http://myserver.com/notsecure.php?password=ralph
I get:

<HTML>
<HEAD>
</HEAD>
<BODY>
Password incorrect. Go away.</BODY>
</HTML>

Note that there's no PHP code in either output. If I guess the
password wrong I do *not* see the correct one. If your server does
not work that way, you have PHP or your web server installed wrong.
Or perhaps not at all.

[color=blue][color=green][color=darkred]
>>>If one was to implement user authorisation (or any other module whose
>>>logic needs to be kept private)[/color]
>>
>>
>> If the *logic* needs to be kept private, it's probably a
>> security hole.
>>[/color]
>
>wtf are you talking about?. Why would you want the whole world to know
>how you authenticate users (you may just as well publish all your
>usernames/passwords onto the internet if you're that lax about security).[/color]

If publishing the *logic* (not the passwords) of the way you
authenticate users lets people break in, your security already sucks
so bad that you may as well publish your passwords, and you shouldn't
even think about using something that bad. Get something better
(perhaps using Apache's .htaccess, and note that the code for that
is public) or give up.
[color=blue][color=green][color=darkred]
>>>in a PHP module (apart from encypting
>>>the script - which has its own pitfalls) -it makes no sense in having
>>>such a module (script or set of scripts) plainly visible/accesible to
>>>the user - who can inspect your user authentication etc at leisure,[/color]
>>
>>
>> If you're talking about a remote user with a web browser, they
>> *cannot* inspect your PHP code at their leisure.
>>[/color]
>Really ?. See my response to your first answer.[/color]

Fix your PHP installation.
[color=blue][color=green]
>>[color=darkred]
>>>whilst sipping his favourite beverage. What is the way to keep your
>>>script inacesible to users so that they cannot simply FTP or GET your
>>>script - giving that the path and file name has been kindly provided?[/color]
>>
>>
>> Ensure that you provide *NO* path where a user can simply GET your
>> protected files without authenticating. This is typically done
>> with a PHP page which checks the user's authentication, and if it's
>> OK, outputs a Content-type: header, then does a fpassthru() using
>> a file name *outside the document tree*.
>>[/color]
>This seems more like it. But it skirts around the issue. Where do you
>keep the PHP which ckecks the user's authentication? (this was precisely
>my question in the first place).[/color]

In the document tree. I wouldn't keep the *passwords* there (they'd
be in a database, or outside the document tree). And if someone
can figure out how to break in looking at the PHP code only, I
shouldn't even be thinking about using it to protect anything
serious.

Gordon L. Burditt

[ZeldorBlat]

Re: permissions and script 'visibility'


Dave Schwimmer wrote:[color=blue]
> Gordon Burditt wrote:
>[color=green][color=darkred]
> >>I am relatively new to PHP. One of the things that seems glaring obvious
> >>to me (coming from a C/C++ background) is how 'open' everything seems -
> >>(AFAIK). For instance, URLs typically have the name of the php script
> >>that they are calling -[/color][/color][/color]

That would make sense...the webserver needs to know which file to look
in.
[color=blue][color=green][color=darkred]
> >>also just viewing the source of most web pages
> >>will show you in glorious detail, the paths and names to any PHP scripts
> >>they may be using.[/color][/color][/color]

So what? Someone can view your source in their browser and see paths
to JavaScript includes, style sheets and other things as well. In
fact, I would hope that they can download and view them -- if they
can't, then neither can the browser and your website would be pretty
useless.
[color=blue][color=green]
> >
> >
> > HTML is visible. PHP code isn't visible via HTTP.[/color]
>
> WRONG !. It is EXACTLY this kind of laid back approach to security (and
> programming in general) that lets me worry about scripters and scripting
> languages. I have been playing around with PHP in just 2 days, I see an
> obvious security 'hole' and you casually tell me that PHP code isn't
> visible via PHP - well try this for size:
>
> type this at your shell/command prompt and see what you get back:
>
> GET http://yourhostname/notsecure.php HTTP/1.1[/color]

I get a bunch of HTML back just as I would expect. Consider how the
webserver, PHP, and the web browser work to deliver a page:

1) Web browser tells server he wants to get foo.php.
2) Web server processes the request. He knows that foo.php is a PHP
file, so the source code of the script gets sent to the PHP engine.
3) PHP engine processes/executes the script and generates some HTML
which is handed back to the webserver.
4) Webserver takes the HTML and sends it to the web browser.

Note that nowhere along the line is the PHP source code sent to the
browser -- only the output of the script.

Now that's not to say that you can't expose code or other
"behind-the-scenes" stuff. That can happen for a variety of reasons.
For instance:

o You have buggy/poorly written code
o You have not configured the webserver properly
o You have not configured PHP properly
[color=blue][color=green]
> >[color=darkred]
> >>in a PHP module (apart from encypting
> >>the script - which has its own pitfalls) -it makes no sense in having
> >>such a module (script or set of scripts) plainly visible/accesible to
> >>the user - who can inspect your user authentication etc at leisure,[/color]
> >
> >
> > If you're talking about a remote user with a web browser, they
> > *cannot* inspect your PHP code at their leisure.
> >[/color]
> Really ?. See my response to your first answer.[/color]

And see my response above.
[color=blue][color=green]
> >[color=darkred]
> >>whilst sipping his favourite beverage. What is the way to keep your
> >>script inacesible to users so that they cannot simply FTP or GET your
> >>script - giving that the path and file name has been kindly provided?[/color]
> >
> >
> > Ensure that you provide *NO* path where a user can simply GET your
> > protected files without authenticating. This is typically done
> > with a PHP page which checks the user's authentication, and if it's
> > OK, outputs a Content-type: header, then does a fpassthru() using
> > a file name *outside the document tree*.[/color][/color]

That's one way. Alternatively you can use your webserver's
authentication capabilities. Or you can just set a session variable
when a user has successfully logged in and check at the top of the page
that the variable is set.
[color=blue][color=green]
> >[/color]
> This seems more like it. But it skirts around the issue. Where do you
> keep the PHP which ckecks the user's authentication? (this was precisely
> my question in the first place).[/color]

Given that they can't see the source, it doesn't really matter.
[color=blue][color=green]
> >[color=darkred]
> >>I think I remember reading somewhere that this is to do with setting
> >>file permissions - for example placing the scripts in afolder above the
> >>web server doc root. But this begs the question that if the user has no
> >>permision to the folder where the php files are kept - how can he
> >>execute them. Actually, the last sentence made me realise that the way
> >>around this (may?) be to have Apache run as a different user from the
> >>web client. Am I correct in this assumption?. Suggestions welcome.[/color][/color][/color]

So all your clients are running under the same user as Apache? Which
would mean that all your clients are using the web server to do their
browsing? You're confused. Apache (by default) runs as "nobody." The
nobody user has permissions on files just like anyone else. Clearly
he'll need to be able to read whatever file you want to serve.

But just because the nobody user has read permissions on a file doesn't
mean Apache will serve it. So, you can setup a directory structure
like this:

/foo/bar/htdocs
/foo/bar/includes

Give "nobody" read access on both those directories. Now set up Apache
with a docroot of /foo/bar/htdocs. What this basically means is that:

o Clients on the web will be able to get to files in /foo/bar/htdocs
o Clients on the web will not be able to get to files in
/foo/bar/includes
o PHP will be able to get to files in /foo/bar/includes

So even though someone on the web can't request a file in the includes
directory, from inside a PHP script you can still use include() to
include a file in the includes directory.
[color=blue][color=green]
> >
> >
> > If you are attempting to protect against someone who is sharing access
> > to the same server as you are, you're probably screwed.[/color]
>
> True, but its a no brainer to solve that one (just use a dedicated server).[color=green]
> >
> > Gordon L. Burditt[/color][/color]

Both true.

[ZeldorBlat]

Re: permissions and script 'visibility'


Dave Schwimmer wrote:[color=blue]
> samudasu wrote:
>[color=green]
> > To start off with, opening a php file won't show you php code. It only
> > shows the results of the php script after it's run. ftp should be
> > password protected, no one but you will have this password.
> >
> > I've found that placing sensetive files above document_root works
> > nicely like you've mentioned. Here's how it's done:
> > /usr/local/apache/htdocs/ is the doc root.
> > Make a /usr/local/apache/incfiles/ dir to keep sensitive files, db
> > connect srcipts, user/pass info, etc. Users have no direct access to
> > these files since they're not in the doc root. Files in this dir are
> > used with the include() or require() functions. Users don't need
> > permission to this folder so there are no special permissions required.
> > The apache user (usually nobody) will access the files.
> >
> > example:
> > /usr/local/apache/htdocs/verifylogin.php is a page you can guess what
> > it does.
> > I want to include() the script
> > "/usr/local/apache/incfiles/chkpass.inc.php " in verifylogin.php that
> > connects to the db and check the clients username password.
> >
> > verifylogin.php ...
> >
> > <?php
> > include'../incfiles/chkpass.inc.php ';
> > ?>
> > <html>
> > <body>
> > <?php
> > if user/pass correct
> > show this
> > if user/pass failed
> > show this
> > ?>
> > </body>
> > </html>
> >
> > If you view source of verifylogin.php you'll see no php code and no
> > path / reference to /usr/local/apache/incfiles/chkpass.inc.php .
> >[/color]
>
> Thank you. This is PRECISELY the sort of information I was looking for.[/color]

Since you seem to be pretty worried about this "problem," here's how
you can take samudasu's solution one step further.

Create a file called protectInclude. php and put this in there:

<?php
if(!defined('my App') || myApp == false)
die("You shouln't be here.");
?>

Now, at the top of any file that a web client shouldn't be able to
access directly put the following:

<?php require("protec tInclude.php"); ?>

And finally, at the top of any file that /is/ a valid entry point,
put:

<?php
define('myApp', true);
?>

In this manner, even if you screw something else up, you won't get
burned.

[Jerry Stuckle]

Re: permissions and script 'visibility'

Dave Schwimmer wrote:[color=blue]
>
>
> Gordon Burditt wrote:
>[color=green][color=darkred]
>>> I am relatively new to PHP. One of the things that seems glaring
>>> obvious to me (coming from a C/C++ background) is how 'open'
>>> everything seems - (AFAIK). For instance, URLs typically have the
>>> name of the php script that they are calling - also just viewing the
>>> source of most web pages will show you in glorious detail, the paths
>>> and names to any PHP scripts they may be using.[/color]
>>
>>
>>
>> HTML is visible. PHP code isn't visible via HTTP.[/color]
>
>
> WRONG !. It is EXACTLY this kind of laid back approach to security (and
> programming in general) that lets me worry about scripters and scripting
> languages. I have been playing around with PHP in just 2 days, I see an
> obvious security 'hole' and you casually tell me that PHP code isn't
> visible via PHP - well try this for size:
>
> type this at your shell/command prompt and see what you get back:
>
> GET http://yourhostname/notsecure.php HTTP/1.1
>[/color]

Gordon is correct. HTML is visible. PHP is not.

And from your operation I get the HTML - not the PHP code.

If you're getting something else, you have things set up improperly.
[color=blue][color=green]
>>
>>[color=darkred]
>>> If one was to implement user authorisation (or any other module whose
>>> logic needs to be kept private)[/color]
>>
>>
>>
>> If the *logic* needs to be kept private, it's probably a
>> security hole.
>>[/color]
>
> wtf are you talking about?. Why would you want the whole world to know
> how you authenticate users (you may just as well publish all your
> usernames/passwords onto the internet if you're that lax about security).
>
>[/color]

Again - it's not available.
[color=blue][color=green]
>>[color=darkred]
>>> in a PHP module (apart from encypting the script - which has its own
>>> pitfalls) -it makes no sense in having such a module (script or set
>>> of scripts) plainly visible/accesible to the user - who can inspect
>>> your user authentication etc at leisure,[/color]
>>
>>
>>
>> If you're talking about a remote user with a web browser, they
>> *cannot* inspect your PHP code at their leisure.
>>[/color]
> Really ?. See my response to your first answer.
>[/color]

Really.
[color=blue][color=green]
>>[color=darkred]
>>> whilst sipping his favourite beverage. What is the way to keep your
>>> script inacesible to users so that they cannot simply FTP or GET your
>>> script - giving that the path and file name has been kindly provided?[/color]
>>
>>
>>
>> Ensure that you provide *NO* path where a user can simply GET your
>> protected files without authenticating. This is typically done
>> with a PHP page which checks the user's authentication, and if it's
>> OK, outputs a Content-type: header, then does a fpassthru() using
>> a file name *outside the document tree*.
>>[/color]
> This seems more like it. But it skirts around the issue. Where do you
> keep the PHP which ckecks the user's authentication? (this was precisely
> my question in the first place).
>[/color]

I keep mine in web pages where the code can't be seen.
[color=blue][color=green]
>>[color=darkred]
>>> I think I remember reading somewhere that this is to do with setting
>>> file permissions - for example placing the scripts in afolder above
>>> the web server doc root. But this begs the question that if the user
>>> has no permision to the folder where the php files are kept - how can
>>> he execute them. Actually, the last sentence made me realise that the
>>> way around this (may?) be to have Apache run as a different user from
>>> the web client. Am I correct in this assumption?. Suggestions welcome.[/color]
>>
>>
>>
>> If you are attempting to protect against someone who is sharing access
>> to the same server as you are, you're probably screwed.[/color]
>
>
> True, but its a no brainer to solve that one (just use a dedicated server).
>[color=green]
>>
>> Gordon L. Burditt[/color]
>
>[/color]

I suggest you learn more about how PHP and web servers work before you
start throwing stones.


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Ben Bacarisse]

Re: permissions and script 'visibility'

On Sat, 18 Feb 2006 03:23:56 +0000, Dave Schwimmer wrote:
[color=blue]
> type this at your shell/command prompt and see what you get back:
>
> GET http://yourhostname/notsecure.php HTTP/1.1[/color]

What am I missing here? I have no GET command. Do you mean run something
that issues and HTTP/1.1 GET request? If so, why would it do anything
different from a browser?

BTW, you are right that PHP can sometimes be seen but it requires a server
error. I had a site merrily sending PHP source for serveral hours before
the hosting company fixed the server configuration!

--
Ben.

[Jasen Betts]

Re: permissions and script 'visibility'

On 2006-02-18, Dave Schwimmer <dschwim@nospam .com> wrote:[color=blue]
>
>
> Gordon Burditt wrote:
>[color=green][color=darkred]
>>>I am relatively new to PHP. One of the things that seems glaring obvious
>>>to me (coming from a C/C++ background) is how 'open' everything seems -
>>>(AFAIK). For instance, URLs typically have the name of the php script
>>>that they are calling - also just viewing the source of most web pages
>>>will show you in glorious detail, the paths and names to any PHP scripts
>>>they may be using.[/color]
>>
>>
>> HTML is visible. PHP code isn't visible via HTTP.[/color]
>
> WRONG !. It is EXACTLY this kind of laid back approach to security (and
> programming in general) that lets me worry about scripters and scripting
> languages. I have been playing around with PHP in just 2 days, I see an
> obvious security 'hole' and you casually tell me that PHP code isn't
> visible via PHP - well try this for size:
>
> type this at your shell/command prompt and see what you get back:
>
> GET http://yourhostname/notsecure.php HTTP/1.1[/color]

bash: GET: command not found
[color=blue][color=green][color=darkred]
>>>If one was to implement user authorisation (or any other module whose
>>>logic needs to be kept private)[/color]
>>
>> If the *logic* needs to be kept private, it's probably a
>> security hole.[/color]
>
> wtf are you talking about?. Why would you want the whole world to know
> how you authenticate users (you may just as well publish all your
> usernames/passwords onto the internet if you're that lax about security).[/color]

you appear to be talking about security through obcsurity.

what good does it do them to know the name of the table that holds the user
records.
[color=blue][color=green][color=darkred]
>>>in a PHP module (apart from encypting
>>>the script - which has its own pitfalls) -it makes no sense in having
>>>such a module (script or set of scripts) plainly visible/accesible to
>>>the user - who can inspect your user authentication etc at leisure,[/color]
>>
>>
>> If you're talking about a remote user with a web browser, they
>> *cannot* inspect your PHP code at their leisure.
>>[/color]
> Really ?. See my response to your first answer.[/color]

Your first response is nonsense, neither a common command-line tool or a
valid HTTP request,


but since you put such great store in it I'll try it as a correctly
formatted HTTP request.

$ nc localhost 80
..GET /notsecure.php HTTP/1.1
..Host: localhost
..
..HTTP/1.1 404 Not Found
..Date: Sun, 19 Feb 2006 00:31:41 GMT
..Server: Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16
..Content-Length: 310
..Content-Type: text/html; charset=iso-8859-1
..
..<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
..<html><head>
..<title>404 Not Found</title>
..</head><body>
..<h1>Not Found</h1>
..<p>The requested URL /notsecure.php was not found on this server.</p>
..<hr>
..<address>Apac he/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16 Server at localhost
..Port 80</address>
..</body></html>

about all they can tell from that is My O/S, server version, and version of
PHP
[color=blue][color=green]
>> Ensure that you provide *NO* path where a user can simply GET your
>> protected files without authenticating. This is typically done
>> with a PHP page which checks the user's authentication, and if it's
>> OK, outputs a Content-type: header, then does a fpassthru() using
>> a file name *outside the document tree*.[/color]
>
> This seems more like it. But it skirts around the issue. Where do you
> keep the PHP which ckecks the user's authentication? (this was precisely
> my question in the first place).[/color]

what difference does it make? they can't see inside it.

--

Bye.
Jasen

[Jasen Betts]

Re: permissions and script 'visibility'

On 2006-02-18, Dave Schwimmer <dschwim@nospam .com> wrote:[color=blue]
> I am relatively new to PHP. One of the things that seems glaring obvious
> to me (coming from a C/C++ background) is how 'open' everything seems -
> (AFAIK). For instance, URLs typically have the name of the php script
> that they are calling - also just viewing the source of most web pages
> will show you in glorious detail, the paths and names to any PHP scripts
> they may be using.[/color]

state has to be propogated somehow.
[color=blue]
> If one was to implement user authorisation (or any other module whose
> logic needs to be kept private) in a PHP module (apart from encypting
> the script - which has its own pitfalls) -it makes no sense in having
> such a module (script or set of scripts) plainly visible/accesible to
> the user - who can inspect your user authentication etc at leisure,
> whilst sipping his favourite beverage. What is the way to keep your
> script inacesible to users so that they cannot simply FTP or GET your
> script - giving that the path and file name has been kindly provided?[/color]

that can all be hidden.
visible ??? they can see the box, but not the content, just don't leave
backups lying around, it's good practice to write them to be secure even if
their content is revealed..
[color=blue]
> I think I remember reading somewhere that this is to do with setting
> file permissions - for example placing the scripts in afolder above the
> web server doc root. But this begs the question that if the user has no
> permision to the folder where the php files are kept - how can he
> execute them. Actually, the last sentence made me realise that the way
> around this (may?) be to have Apache run as a different user from the
> web client. Am I correct in this assumption?. Suggestions welcome.[/color]

typically apache runs in a different city to the web client... not sure what
you mean.



--

Bye.
Jasen
[B