Posted by Dave Schwimmer on 02/18/06 05:23

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 - 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.
>
>
> 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

>
>
>>If one was to implement user authorisation (or any other module whose
>>logic needs to be kept private)
>
>
> If the *logic* needs to be kept private, it's probably a
> security hole.
>

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).


>
>>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.
>
>>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*.
>
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).
>
>>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.
>
>
> 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

[Back to original message]