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

[Jeff Newmiller]

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.  Further,
how do you know it doesn't exist?  We weren't talking about _your_
particular directory structure.

> 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.

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
---------------------------------------------------------------------------