[nycbug-talk] Searching for suspect PHP files...

Miles Nordin carton at Ivy.NET
Tue Mar 3 17:15:44 EST 2009


>>>>> "hz" == Hans Zaunere <lists at zaunere.com> writes:
>>>>> "mg" == Max Gribov <max at neuropunks.org> writes:
>>>>> "ak" == Andy Kosela <akosela at andykosela.com> writes:

    hz> Is C flawed because someone doesn't know how to check/prevent
    hz> buffer overflows?

emphatically, YES.

Now don't get contrary on me, Hans.  Let's burn a few of these
strawmans before the thread gets hot.  

Claiming something is ``flawed'' is not the same as claiming ``there
is never a case to use it, ever.''  (disagree)

However, saying ``there is a case to use it'' (agree) is not the same
as saying 

``they all have their strengths and weaknesses so it's a matter of
choosing the right tool for the job, or of personal preference with no
overall judgement possible.''  (disagree)

    hz> Is Unix flawed because root let's you wipe out the hard disk?

That is not a security flaw.

    mg> i bet you can find just as many vulnerable web apps written in
    mg> other languages,

National Vulnerability Database, 2008-09-20, 
  notPHP:
    9 records for Plone
  PHP:
    145 Drupal, 
    259 Joomla!, 
    149 WordPress

source: http://en.wikipedia.org/wiki/Plone_(software)  

 :p

I suspect you'll find the same in any other arena where PHP and
non-PHP software are in competition.

    ak> PHP is flawed by design, and not asking "how to write
    ak> secure code".

agree

I am more interested in how to design environments where writing
secure software is effortless.  mysql_real_escape_string is just the
very tip of a huge ``not effortless'' iceberg that explodes underwater
into lack of type safety, no uniform installation environment, a
proliferation of archaic and arcane config knobs that forcibly bleed
across applications, version skew nightmares, bleeding global state,
runtime parsing, and shell-script-type languages based on ``quoting''
and ``substitution'' in general---every time I see & bleeding into
the rendered text on Facebook or \' rendering onto my screen in this
shopping cart software, or website logins that won't take punctuation
in passwords, I think PHP, you doomed piece of shit, you.  

I do not love you.  I will NEVER love you.  Even if you were clean I
would not love you.

    ak> It is so easy to exploit PHP bugs, that even Visual BASIC
    ak> "idiots" can do it.

aye, maybe so, but I didn't originally mean to call the exploiters
idiots.  I meant, are the PHP webapps habitually insecure because PHP
is the low-entry-barrier language for people who spend no effort
understanding the various merits to which a programming language can
aspire, so all the worst programmers collect there, and these guys
could not write a secure webapp in any language?  and my current
answer is, I don't think so, I think the problem is mostly PHP and
that the same idiots would do much better work on another language.

    ak> Miles remarked wisely that
    ak> this trend has been going for years.

yeah, and the full size and shape of the so-called ``web security''
trend may be new, like FX was pointing out lurking problems with Java
webapps that like to ``serialize'' things, because you can feed a
bitstream to the web server and have it explode into some arbitrarily
complicated Object inside the web server J2EE VM.  And you pointed out
problems with super-convenient AJAX environments that encourage
developers to forget the client VM is not trustworthy.  new!

But ``PHP is a pathologically-insecure piece of shit with such a
mountain of documented incidents it's hardly worth discussing the
`why' of the matter, just run, run away, from this awful Situation''
is certainly not new.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20090303/1f2f8824/attachment.bin>


More information about the talk mailing list