[PLUG] Preventing Probes Like This

[Ron Chmara]

Eric Wilhelm wrote:
> # from Ronald Chmara
> # on Tuesday 26 August 2008 03:04:
>   
>> 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?
>   
http://us.php.net/manual/en/features.safe-mode.php#ini.open-basedir

Unfortunately, what seems at first blush to be a fairly simple thing can 
get pretty complex, pretty fast (PHP's "safe_mode" has a whole, uhm, 
history.). Putting this level of restriction on a general default 
per-apache-process level, for example, can lead to hundreds of "allowed 
directories" in the web roots on a shared server available to PHP 
processes (one directory for each vhost), with possibly multiple PEAR 
include libraries for different users, so it's really something that 
should be handled on a per-script, per-program execution cycle, level 
(as required).... back to square one, though, if the programmers simply 
can't be bothered to write more secure code, or intentionally dodge the 
built-in features designed to keep themselves from shooting at their feet.

> 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.)
"all tend to..." might be a little broad....  :D as far as "convenience 
over security", that's up to the programmer. If, for example, a 
programmer wants to use prepared statements, transactions, and 
language-specific-db-string-escaping for SQL, they can. If they want 
straight raw SQL client, convenience, and speed, and are willing to 
suffer the potential drawbacks, they can.


> So, maybe the developers which PHP attracts would actually be better off 
> with a javascript or otherwise jailed+stripped+managed framework?
>   
Yeah, they'd never get bitten by XSS bugs that way, right?... ;)

I think the challenge is in trying to write a software application 
language that doesn't allow people to easily shoot themselves in the 
foot.... yet is still powerful enough to do all of the tasks they want, 
even if that task happens to be, uhm, easily shooting one's self in the 
foot.


-Bop