Re: Fixing stupid PHP application design flaws
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.
> > 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.
> it. Everything a normal user installs is still a problem and even a
> bigger problem then the packages from debian. Also I counted 95 packages
> depending on php4 in Sarge at the moment versus way to many entries when
> you query freshmeat?
What are you trying to say?
> > These files should not be accessible via HTTP in the first place but
> > put into /usr/share/something instead and included from there.
>
> Is this going to solve the problems? Don't get me wrong, because I love
Yes. It would solve the problem of accessing include files that
shouldn't be accessed via HTTP since they weren't designed to be silent.
> your goal but I don't believe that what you suggesting right now is
> going to solve the problems with PHP at this moment. Maybe its an idea
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.
> to get in contact with Rasmus about securing PHP, because he's trying to
> get a more secure and sane php4.ini in the upstream releases. Unluckily
Securing PHP is a laaaaaaarge goal.
> Beside the fact that your plan has some issues with multiple
> installations because some application require that for multiple vhosts.
No. Include files should be vhost-agnostic. If they aren't, a lot
has gone wrong during implementation. It should be sufficient to just
install the accessible PHP files a second time and maybe adjust the
database or other local storage, i.e. a differend config file.
> It may be a better idea to start with PHP itself and ask during
> installation of the users wants to install a secure or insecure version
> of php4.ini. The same is done with setuid issues for example.
There is no secure version of php4.ini.
> > As examples see the following problems:
> >
> > CAN-2005-0459 - information disclosure in phpmyadmin
>
> This one goes even further then information disclosure and isn't the
> reason you want it out of your docroot at this moment. Using unchecked
> variables isn't wise at all time.
You could say this problem is twofold...
> > CAN-2005-0870 - cross site scripting in phpsysinfo
>
> Another example of what Rasmus is fighting for the last couple of years.
> Make the default php4.ini more sane and secure.
That won't work. This is broken by design. In the application.
PHP only provides the tools to shoot oneself in both feet, but others
do as well. There's nothing wrong with it. You don't have to do it...
Regards,
Joey
--
Never trust an operating system you don't have source for!
Reply to: