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

[leam hall]

Ah, so you're saying that cars are bad because there are dumb drivers that
can't replace an engine?

Is there bad code written in PHP? Sure. Same for Python, Perl, C(++/sharp)
etc. Don't blame the language for the users.

Leam


On Mon, Jul 22, 2013 at 9:47 AM, Michael B. Trausch <mbt at naunetcorp.com>wrote:

>  On 07/21/2013 04:44 PM, Andy Borgmann wrote:
>
> Where do you see this being a PHP non-security.  It sounds like it was an
> updated version of vBulletin's admin panel that had a security flaw.  Even
> if vBulletin is coded in PHP, I don't see why blaming PHP as a whole is
> warranted in this case and not just vBulletin.  PHP seems secure enough or
> Facebook.
>
>
> Some points:
>
>    1. Facebook does not run the official PHP, they run a subset of it
>    that is then compiled, if memory serves, to C++ and then compiled to system
>    code.
>    2. PHP itself is insecure for *many* reasons, the least of which:
>       1. PHP has never deprecated functionality that is known-unsafe,
>       given the average experience of the PHP-only programmer; for example, SQL
>       injection attacks are pandemic in PHP code not because it's any less safe
>       than C, but because it is just as safe as C and PHP-only programmers don't
>       have perspective from which to draw from to secure their own code.  This
>       flaw could be fixed in PHP by removing functions that permit it; in my
>       book, that makes it a PHP flaw (it's easier to fix PHP than it would be to
>       fix all PHP programmers).
>       2. PHP has a large number of pseudoprogrammers that work with it.
>       These people are mostly management types that found that they can quickly
>       piece together a PHP script and make it do something useful.  These people
>       have no background in security, information technology, information systems
>       or any similar such topic.  They often C&P pathologically, and the systems
>       that they create are swiss cheese from a security perspective.  Again, this
>       is something that can be fixed in PHP, by ensuring that variables that come
>       from the user are always represented in a canonical format and that outputs
>       are properly escaped.
>       3. PHP has a large number of what I call "auto-fsck-you" features
>       built-in to it that most people do not understand.  One such example is
>       PHP's associative arrays, which are really integer arrays. The reason that
>       integers and string keys can both be used in PHP in the same array is that
>       they share the same namespace; a very large sequential array is quite
>       likely to clash with the hashed namespace used for string keys.  Fun, yes?
>       And that's just one example.
>
> I could go on for pages, but there are many others who have done so at
> length; I won't reinvent the wheel here.  I can say, though, that a quick
> review of US-CERT data shows that PHP and applications written in it are
> still among the most common of security problems—even in systems written by
> professional programmers.
>  --
>   [image: Naunet Corporation Logo]  Michael B. Trausch
>
> President, *Naunet Corporation*
> ☎ (678) 287-0693 x130 or (888) 494-5810 x130
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>


-- 
Mind on a Mission <http://leamhall.blogspot.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/f6e241f2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcdjeaha.png
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/f6e241f2/attachment.png>