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

leam hall leamhall at gmail.com
Mon Jul 22 09:54:05 EDT 2013


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>


More information about the Ale mailing list