[PLUG] Preventing Probes Like This

[Eric Wilhelm]

# from Ronald Chmara
# on Tuesday 26 August 2008 03:04:

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

Yes.  I would hope you were doing some authentication in that case.  But 
still, what I said is that you want a method for addressing filenames 
within the webroot which throws an error when handed an out-of-bounds 
filename.  If you actually set the webroot to /etc/ (though I wouldn't 
do this, even if it were a sysadmin app), well that isn't 
out-of-bounds, is it?

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

No.  That's the wrong debate.  One *could* have a framework (like the 
google appengine will supposedly be) which eliminates I/O methods from 
the language or replaces them with virtualized and managed code.  If 
you want to provide shared hosting to untrusted programmers, this is 
what you need to do.  Or you could use javascript on the server.  You 
still have a chance of leaking information.

But in general, the language itself doesn't need to jail you.  Rather, 
it (or a module/framework) should provide a good set of functions for 
doing the right thing.  In this case, the context is "web application", 
so your DTRT methods need to take the webroot and etc into account.  If 
the tool doesn't make it absolutely easy to do the right thing, it 
probably isn't the right tool.

In the PHP case, you have a lot of core language functions which are 
specifically designed for use in web applications, yet they all tend to 
place convenience over security (so much so that you would think this 
was some kind of templating language hacked together in an afternoon's 
worth of Perl.)  Having both would not be so difficult, but the 
language design doesn't go there.  It would have been simple to make 
the potentially insecure functionality require a bit of extra 
code/input (hey, just have yet another function with the 
prefix 'unsafe_' -- what's 400 more functions in the core syntax?), but 
what you got is the opposite:  extra coding will get you potentially 
secure functionality.

So, maybe the developers which PHP attracts would actually be better off 
with a javascript or otherwise jailed+stripped+managed framework?

--Eric
-- 
As an old bass player friend of mine used to say: throw money, don't 
clap.
--Tony Parisi
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------