|
BugTraq
Re: Re: PHP security (or the lack thereof) Jun 21 2006 11:52PM nabiy hotmail com (2 replies) Re: PHP security (or the lack thereof) Jun 24 2006 05:07AM Ronald Chmara (ron Opus1 COM) (1 replies) RE: PHP security (or the lack thereof) Jun 26 2006 04:06PM Geo. (geoincidents nls net) (3 replies) Re: PHP security (or the lack thereof) Jun 26 2006 05:45PM Paul Schmehl (pauls utdallas edu) (1 replies) Re: PHP security (or the lack thereof) Jun 26 2006 05:32PM Matthias Kestenholz (lists spinlock ch) (1 replies) RE: PHP security (or the lack thereof) Jun 27 2006 11:41AM Geo. (geoincidents nls net) (1 replies) Securing PHP or finding PHP alternatives (was: PHP security (orthe lack thereof)) Jul 08 2006 02:48AM Gezim Hoxha (gezimetc shaw ca) (4 replies) Re: Securing PHP or finding PHP alternatives Jul 11 2006 06:21AM Michael Shigorin (mike osdn org ua) Re: Securing PHP or finding PHP alternatives (was: PHP security (or the lack thereof)) Jul 10 2006 08:37PM Meet Myself on the Internet (me arteabstracta net) Re: Securing PHP or finding PHP alternatives (was: PHP security (orthe lack thereof)) Jul 10 2006 07:25PM Matthias Kestenholz (lists spinlock ch) Re: Securing PHP or finding PHP alternatives Jul 10 2006 05:37PM Crispin Cowan (crispin novell com) (2 replies) Re: Securing PHP or finding PHP alternatives Jul 11 2006 02:50PM Sheryl Coppenger (gubydala his com) (2 replies) Re: Securing PHP or finding PHP alternatives Jul 18 2006 09:35PM Michael Cordover (michael cordover gmail com) Re: Securing PHP or finding PHP alternatives Jul 11 2006 07:54AM SkyFlash (webmaster hackquest de) (1 replies) Re: PHP security (or the lack thereof) Jun 23 2006 08:16PM Crispin Cowan (crispin novell com) (3 replies) Re: PHP security (or the lack thereof) Jun 24 2006 12:43PM Glynn Clements (glynn gclements plus com) Re: PHP security (or the lack thereof) Jun 24 2006 08:28AM Daniel Hulme (bugtraq doublezero uklinux net) |
|
Privacy Statement |
> That's a rather odd question. Microsoft has been (rightly) criticized
> for providing server *applications* that are insecurely configured (as
> you point out), but php is not an application. Php is a language, so
> until a program or script is written and accessible from the server, it
> does nothing. Php, by itself, is not accessible externally because it's
> not running a daemon that opens a port.
I don't agree.
There are lots of web programs written in perl, asp, even cold fusion. But
when I watch the security lists I see exploit after exploit for web
applications and the vast majority of them have one thing in common, they
are written in PHP.
I'm not blaming PHP but you can't just ignore that and say it's meaningless,
it's an obvious pattern and it points to a problem with either the language
or the way it's configured or used. Whatever the reason, if we are going to
have a secure internet environment then people need to be aware of the
problem and solutions.
All that I've been suggesting is that SANS points out this danger, make
people aware that PHP based applications are being exploited at these levels
and focus attention on the problem. Perhaps a table of popular PHP based
applications and a count column of the number of exploits each has had to
patch so folks can make an informed decision when looking for php based web
apps.
Geo.
[ reply ]