[PLUG] Preventing Probes Like This
Ronald Chmara
ronabop at gmail.com
Tue Aug 26 10:04:32 UTC 2008
On Aug 25, 2008, at 3:56 PM, Eric Wilhelm wrote:
> # from Ron Chmara
> # on Monday 25 August 2008 14:59:
>
>> Of course, the counter argument to making this easy is noted in this
>> very thread, as PHP was allowed to easily read /etc/passwd (it's a
>> file on the hard disk, why shouldn't PHP be able to read it?...), and
>> yet, there was an implied expectation that PHP "shouldn't be able to
>> do that".
>
> That's not really it. If you do open(my $fh, '<', '/etc/passwd'), you
> get that. If you're just trying to display some bit of text that's
> supposed to be next to you in the webroot, your tool (especially a
> very
> web-centric tool) should give you a default way to do that which
> limits
> the filenames to within the webroot.
If your webroot for the application is /etc/, because your particular
application is a sysadmin application, /etc/passwd being read-
accessible makes perfect sense.
There are many good arguments for many different PHP behaviors. :)
> The framework should give you convenient tools for doing
> the sensible thing. It can still give you plenty of rope, but handing
> me a neatly coiled rope is completely different from handing me a
> bucket full of knots.
You somewhat lost me, but I would guess that the general debate
focuses on the issue of whether PHP/perl/python/C/java/bash/
<whatever> should be limited to being a jailed "DocumentRoot"
language, or a language that can inherit the permissions of a parent
process.
Perhaps part of the "mental problem" is that people who deployed PHP
on their servers did not realize how much power it had. This is not a
new mistake, just an old one, repeated. If users should not be
allowed C/bash/perl level scripting, then, well, shut off PHP?
-Bop
More information about the PLUG
mailing list