|
|
Posted by ZeldorBlat on 02/18/06 06:22
Dave Schwimmer wrote:
> Gordon Burditt wrote:
>
> >>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 -
That would make sense...the webserver needs to know which file to look
in.
> >>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.
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.
> >
> >
> > HTML is visible. PHP code isn't visible via HTTP.
>
> 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
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
> >
> >>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,
> >
> >
> > If you're talking about a remote user with a web browser, they
> > *cannot* inspect your PHP code at their leisure.
> >
> Really ?. See my response to your first answer.
And see my response above.
> >
> >>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?
> >
> >
> > 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*.
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.
> >
> 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).
Given that they can't see the source, it doesn't really matter.
> >
> >>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.
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.
> >
> >
> > If you are attempting to protect against someone who is sharing access
> > to the same server as you are, you're probably screwed.
>
> True, but its a no brainer to solve that one (just use a dedicated server).
> >
> > Gordon L. Burditt
Both true.
Navigation:
[Reply to this message]
|