|
|
Posted by Gordon Burditt on 02/18/06 06:11
>>>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 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.
>>>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).
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.
>>>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.
Fix your PHP installation.
>>
>>>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).
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
[Back to original message]
|