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

Mon Jul 22 09:57:25 EDT 2013

Facebook hasn't had any hacks that I am aware of.  I know they release a
lot of information via Graph and other areas, which leads many of us to
feel uncomfortable with there security practices.  But it seems all the
information that is released, is released by design.  And I don't see how
just because they run PHP through HipHop (which they created) to run there
code through C and C++ for *performance reasons* makes it anymore secure
than standard PHP?

Also, just because PHP can be written poorly and that it attracts beginner
developers, doesn't mean that it is by itself an insecure language - it
just means those applications with poor coders are insecure.  Also, your
reason #3 would speak to the inefficiency of PHP but I don't see how it
speaks to the insecurity of PHP.

To me the larger issue always seems to be with code that is available for
public distribution (i.e. WordPress, phpBB, etc...).  If people can peer
into the code and find the vulnerabilities and exploit un-updated versions
of it, it makes sense that *they* are insecure.  But not that the platform
itself is insecure.  But if you're code is never released publicly, and you
take good measure to secure the server (which is more of a Linux thing
anyways assuming a LAMP stack), then how is it PHP's fault?

Also, isn't SQL injection pretty much fixed with Magic Quotes?  I had a
security guy from GA Tech test my site once and was unable to SQL inject
attack the site.  I thought this was largely due to the fact that any
$_POST to the site is automatically escaped via Magic Quotes.

I appreciate the articles Charles has submitted.  I will read those for
sure.

*
*
*--*
*Andy Borgmann*

E-mail: andy at borgmann.me
Cell Phone: (404) 492-6527
Personal Website: http://andy.borgmann.me/<http://andy.borgmann.me/?r=email>

"*Preach the Word; be prepared in season and out of season; correct,
rebuke and encourage - with great patience and careful instruction.*" -
2Timothy 4:2

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/4350cf2d/attachment-0001.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/4350cf2d/attachment-0001.png>