Re: Fixing stupid PHP application design flaws
On Sat, Apr 30, 2005 at 07:55:31AM +0200, Martin Schulze wrote:
> Hans Spaans wrote:
> > Martin Schulze wrote:
> > > Hey!
> > >
> > > What do people on this list think about fixing PHP include files in a
> > > DSA that are accessible via HTTP as well and contain one bug or
> > > another as they are not supposed to be accessible via HTTP but
> > > accidently are.
> >
> > Patching them like Squirrelmail has fixed this may be a better solution
> > before everything is in place.
>
> >From a first look, this is what I proposed, yes.
>
> Having /usr/share/$package for the include files and
> /var/lib/$package for the executable PHP scripts that should be linked
> into the web server.
Eh, that's now how squirrelmail works. All stock php files are in
/usr/share/$package, and that's also what's used from the default apache
config for squirrelmail. The config dir is symlinked from thew webroot
to /etc, and so is that attachment spool symlinked to the appropriate
/var/spool link. While all config files are accessible via the web, they
have .php and are a no-op when executed seperately.
Having non-dymanic files in /var/lib would be an FHS violation. The only
thing squirrelmail has in /var/lib is the per-user configuration files,
that are stored by using squirrelmail.
Squirrelmail is in no way different than many other php applications. I
agree it'd be nice for etch to have some proper policy in place to
actually disallow this kind of stuff, and to urge upstreams to support
that easily (while they probably will stick to their default of having
include & config in subdirs, they can at least make sure that changing
that is only the matter of changing one or a few vars/something).
> > > I'm rather annoyed by the lack of comptence of some PHP coders who
> > > manage their project in a way so that include files are stored within
> > > the regular DocumentRoot and are hencely accessible via HTTP as well.
> > > Include files normally also don't contain any precaution about being
> > > "executed" standalone.
> >
> > I both agree and disagree with you. The reason I disagree with you, is
> > that this works fine for php scripts that come with debian, but thats
>
> No. But it would work in Debian at least.
>
> It is no problem to provide a tarball (or zip file) with the following
> contents:
>
> www/ - all files that need to be beneath DocumentRoot
> include/ - all files that are included
> foo.conf - becomes /etc/foo/foo.conf and contains the path to include
>
> Even less competent users should be able to install these three
> components on a bare system. You can also provide a simple Makefile
> to accomplish this task. Such things worked for other packages as
> well.
"Simple makefile" doesn't match the typical person installing a web
application. A .tar.gz may already be too difficult, they want to be
able to ftp their files to their provider and it should work. Also, this
doesn't work if one cannot write to an area above the exported
directory, which happens: people that are only able to upload stuff to
the webroot. As noted above, upstream could provides in the root of the
exported files a 'where is my config & where are my includes' file, that
distributions can change, and by default will be ./includes and ./config
or something.
> It's not a problem with PHP but with web applications written in PHP.
>
> I can imagine that similar problems exist with eperl, epython, pike or
> any other languages embedded in the web space that weren't developed
> thoroughly.
PHP is provided by nearly all webhosting companies, and lots of php
applications are targetted at the not-so-clueful users. Hence the choice
for all-in-webroot.
> There is no secure version of php4.ini.
Yeah, it comes down to the application not doing stupid things at any
time, most of the settings only provide a false sense of security.
Register-globals setting 'off' (which is the default in sarge) is a way
to prevent a lot of potential bugs though.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: