Re: Directory traversal in source.php not fixed.

[Kaf Oseo <kaf () szub net>]

Seth,

Thank you again.

I've personally not found a difference in efficiency between strstr and 
strpos. However, I'll look into whether this is case for my script. As 
my main concern is with the path traversal issue brought up (naturally), 
and these two lines:

$file = (strstr($file_get, '..') == true) ? NULL : $file_get;
$file = (strpos($file_get, '..') === false) ? $file_get : NULL;

appear to be functionally equivalent, I can take a little time testing 
strpos vs. strstr for speed and memory use.

I agree with your Perl observation, but then you work with the tools for 
the job at hand.

Just another monkey, :)
-Kaf

Seth Alan Woolley wrote:
 > Actually, if I'm not mistaken again ;), it would be faster this way
> while still getting strpos speed advantages:
>
> $file = (strpos($file_get, '..') === false) ? $file_get : NULL;
>
> Note how we're testing for false and negating now -- I earlier made the 
> mistake that (!(a === false)) is the same thing as (a === true), but 
> they aren't because of the type munging going on (I'm really not used to 
> php's type munging semantics).
>
> I suggested === in my first proposed fix because php.net says to use it 
> to test the return value, but they aren't explicit that this will only 
> work on false.  strpos is also faster than strstr, according to 
> php.net's manual of strstr.
>
> I'll note that perl's index function is actually sane in that it uses a 
> _different_ integer value for not found than one that overlaps with the 
> valid set of found index positions:
>
>        index STR,SUBSTR,POSITION
>        index STR,SUBSTR
>              The index function searches for one string within another, but
>              without the wildcard-like behavior of a full regular-expression
>              pattern match.  It returns the position of the first occurrence
>              of SUBSTR in STR at or after POSITION.  If POSITION is omitted,
>              starts searching from the beginning of the string.  The return
>              value is based at 0 (or whatever you've set the $[ variable
>              to--but don't do that).  *If the substring is not found, returns*
>              *one less than the base, ordinarily "-1".*
>                                                                                                                                       
> Just another reason why perl's so much easier to code secure software 
> in.  I hate having to learn poorly-thought-through functions in php just 
> because monkeys are taught to use it instead of a real scripting 
> language. *sigh*
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/