|
|
Posted by Jasen Betts on 02/19/06 02:40
On 2006-02-18, Dave Schwimmer <dschwim@nospam.com> 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 - 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
bash: GET: command not found
>>>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).
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.
>>>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.
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>Apache/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
>> 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).
what difference does it make? they can't see inside it.
--
Bye.
Jasen
Navigation:
[Reply to this message]
|