Re: Fixing stupid PHP application design flaws
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.
> 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
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?
> 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
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
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
his attempts fail, also because distro builders don't support his
action. It seems not many are interessent in selling a webserver distro
that can't run all the ****ware like phpbb, php(my|pg)admin, phpnuke,
the list is long, out of the box. Personally I don't want a php-script
running a variable as of it was part of its own code or including code
from other untrusted sites.
Beside the fact that your plan has some issues with multiple
installations because some application require that for multiple vhosts.
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.
> 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.
> 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.
But the bottomline for both issues, don't display error messages on
screen, but in a logfile. And also both issues are straight examples out
of the textbooks, where xss can be disabled almost everytime with
changing php4.ini.
Sorry, if this doesn't sound happy, but I'm at the point where I start
to hate PHP, PHP-applications and sysadmins who don't want to tell a
developer/user that his/here application doesn't run because it wants to
do dangerous things. But I'm pleased that these issues are now being
addresses by at least one distro in public.
Hans
Reply to: