[ale] Well, this does nothing for the reputation of Linux

[Michael B. Trausch]

On 07/22/2013 10:15 AM, Andy Borgmann wrote:
> No need to get defensive.  I am not "minding" you, and I am sure you
> are a great programmer and have more experience than me.  My only
> point in this is that PHP is not inherently insecure.  Not saying it
> is better than C or Java or Python.  All I am saying is that the
> security flaws in PHP have more to do with poorly written code that is
> publicly viewable to the world than the system itself, and that the
> examples provided thus far haven't convinced me that it is any less
> secure than I originally knew other than less qualified people use it
> due to the low barrier of entry.

On a technical level, you are correct.

On a practical level, the only way to secure the web of PHP applications
that are out there that would have any chance at being effective would
be to remove PHP's automatic-screw-yous (e.g., the array one is
particularly bad if you've ever been bitten by it---and you'll never,
ever forget it if you do get bit by it, either) as well as remove its
bad ideas.

For example, there should be a standard, inbuilt method for creating
secure SQL queries, and you should have to go out of your way to bypass
it.  IOW, secure by default.  There is, sort of, but the defaults are
still "whatever you want".  C# fixed this problem in its world by
creating an extension to the language that maps directly to database
queries (and it actually was developed for security sake, but it seems
to create far better queries than most humans do by default, so in that
case, security caused a performance benefit, too).

> And I would very much be interested in what you know about HipHop,
> because everything I have read about it and looked into relates to
> performance, not security.

It's been three or four months since I spent any time looking at it. 
I've come back to looking into it with every PHP project I have done,
including the current one.  However, the base requirements for the
project I'm on, once they were decided, excluded HPHP for technical
reasons (the base cannot be compiled with it).

Among the things that weren't supported the last time I checked it out,
and I /believe/ are still unsupported (and these are the overlapping
ones---both technically difficult and insecure):

  * eval---which shouldn't really ever be used anyway, as it allows
    injection to occur upon the compromise of any system trusted to
    inject via that method.
  * dynamic includes---With truly bad code, there is no way to avoid
    them.  Such code cannot ever be compiled by HPHP because the very
    thing it depends on does not exist.  (They do appear to have a new
    mode that runs in a VM that might allow it, but whether they enabled
    such functionality or not is not easily discoverable and I'd have to
    check it out to test it.)  Dynamic includes are worse than most
    people realize because they almost never realize just how easy it is
    to attack and trick a PHP system into including things outside of
    the app's control.

Namespaces weren't implemented, either, the last time I checked, but
that was because they hadn't gotten around to adding support for PHP 5.3
yet.  Those are a great security feature, too.

    --- Mike

-- 
Naunet Corporation Logo 	Michael B. Trausch

President, *Naunet Corporation*
? (678) 287-0693 x130 or (888) 494-5810 x130

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/134b49c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jiifjbbg.png
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/134b49c6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/134b49c6/attachment.sig>