On Fri, December 15, 2006 5:12 pm, Ilia Alshanetsky wrote:
> And here is your first exploit, let's say we say
> mysql_real_escape_string() takes tainted data and makes it untainted,
> what happens when this "safe" data is passed to exec(). You are going
> to need to deal with different levels of taint-untainted and 1 bit is
> not going to give you that flexibility. You are going to need an int/
> long, maybe even a long long.
I think the presumption is that most developers smart enough to be
using mysql_real_escape_string() is PROBABLY smart enough to not just
blindly pass its output to exec().
Or, more likely, that most developers smart enough to use
mysql_real_escape_string() will code more like:
$input = $_REQUEST['input']; //tainted
$input_sql = mysql_real_escape_string($input); //untainted
$input_exec = escapeshellarg($input); //untainted
exec("/whatever $input"); //E_ERROR
Ooops, I made a typo!
So "taint" will only catch, say, 99% of the naive scripters who don't
filter data, and an occasional typo for the experts.
Nobody is claiming it will catch this one:
$input = $_REQUEST['input']; //tainted
$input_sql = mysql_real_escape_string($input); //untainted
$input_exec = escapeshellarg($input); //untainted
exec("/whatever $input_sql"); //false negative, oh well
Still sounds like it's worth considering, if the performance and
maintainability penalties are not too high.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
