[vox-tech] php security (was: another php question)

[Tim Riley]

Jeff Newmiller wrote:

> On Thu, 6 Jun 2002, Tim Riley wrote:
>
> > Samuel Merritt wrote:
> >
> > > On Thu, Jun 06, 2002 at 02:12:25PM -0700, Tim Riley wrote:
> > > >
> > > > Matt Roper wrote:
> > > >
> > > > > With this solution, what keeps people from using something like
> > > > > "../../../etc/shadow" as $arg?  You'd probably need to strip out slashes
> > > > > and ..'s to be safe...
> > > > >
> > > > > Matt
> > > > >
> > > >
> > > > Good thinking Matt and Jeff. How about
> > > >
> > > > $file2open = ( substr( $arg[ 1 ], 0, 1 ) == "." )
> > > >                 ? ""
> > > >                 : $APPLICATION_HOME_DIRECTORY . $arg[ 1 ];
> > > >
> > > > This checks the first character for a dot by using the substring function
> > > > inside the ternary operator. If someone tries to penetrate your system, file2open
> > > > will fail.
> > >
> > > That's not enough. What about foo/../../../etc/shadow ?
> >
> > Samuel, I don't mean to be critical, but the foo directory doesn't exist,
> > so this will fail.
>
> If they can figure out _any_ directory name, conceptually they can do
> this... foo is a conceptual idea, not an actual directory name. <snip>

Oh.

What about:

 $file2open = ( strstr( $arg[ 1 ], ".." ) )
                 ? ""
                 : $APPLICATION_HOME_DIRECTORY . $arg[ 1 ];

Strstr() is the string search function, and here if it finds two adjacent dots, the
ternary operator will successfully return an empty filename. Can a hacker
get out of this jail?


>
>
> > Apache uses the DOCUMENT_ROOT mnemonic as its relative
> > mount point; therefore /etc/everything is protected. (Try opening
> > http://www.lugod.org/etc/passwd or
> > http://www.lugod.org/foo/../etc/passwd)
>
> Perhaps in the cutting room you forgot what we _are_ talking about.  Your
> URL examples were not what was being considered... what _was_ being
> considered was file access from within PHP based on URL arguments that
> Apache does not process, as in
>
>  <A href="display_stats.php3?arg=beetle.dat">beetle</A>
>
> where the malicious user attempts to access
>
> http://yoursite.com/cgi-bin/display_stats.php3?arg=images/../../../etc/password
>
> or some variation thereof to learn what usernames to attack.  Since
> Peter's PHP code would process the "images/../../../etc/password" portion,
> he, not Apache, would be responsible for avoiding going outside his
> sandbox.
>

If Apache can safely pass a filename as a parameter, then so can we. That's
the analogy.

>
> Though I am not a PHP user, this would strike me as a prime candidate for
> a standard feature of this kind of environment.  Looking in the PHP manual
> briefly, I find "realpath", which looks like a good candidate tool to help
> straighten this mess out and allow simple programmatic confirmation that
> the file is in the appropriate area of the filesystem.  There may be even
> better library routines... but this seems pretty easy to build a
> "die_if_someone_is_hacking()" routine with.
>
> > There are many other ways to prevent unscrupulous Internet
> > users from accessing your files; however, they seem complicated.
>
> "A solution should be as simple as possible, but no simpler."
> -- Albert Einstein.
>
> ---------------------------------------------------------------------------
> Jeff Newmiller                        The     .....       .....  Go Live...
> DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
>                                       Live:   OO#.. Dead: OO#..  Playing
> Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
> /Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
> ---------------------------------------------------------------------------
>
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech