full-disclosure - Re: Directory traversal in source.php not fixed.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon Jul  4 21:40:54 2005
From: kaf at szub.net (Kaf Oseo)
Subject: Re: Directory traversal in source.php not fixed.

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*