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

Mon Jul 22 10:23:22 EDT 2013

Hi,

I have been following this debate about PHP. To summarize:

1. PHP has some problems that can easily lead to website vulnerabilities  
if the programmer does not take precautions to prevent. PHP appears to  
have more of these problems than Python/Django, Ruby on Rails, or .NET. So  
if you can use something else, this is the preferred route.

2. PHP being relatively easy to learn and very common for webscripting is  
often used by poorly supervised, inexperience programmers who do not  
security best practices. Whether the programmers know about the best  
practices is often problematic since some are really web designers not  
programmers. Python and Ruby seem to be more complex than PHP but still  
fairly easy to learn. Given many webdesigners do not really like  
programming this could be an issue. I do not know much about .NET or Perl.

The combination of the two can lead to some very disasterous problems for  
a website. Which issue is the most important? I would tend to lean towards  
2 by a nose because even if the PHP problems were largely cleaned up in  
say version 6 an inexperienced programmer will make serious security  
mistakes. Or if another language was used poor coding, and inattention to  
security is still a major problem.

On Mon, 22 Jul 2013 09:57:25 -0400, Andy Borgmann <andy at borgmann.me> wrote:

> 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/
>
> "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:
>> 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.
>> PHP itself is insecure for many reasons, the least of which:
>> 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).
>> 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.
>> 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.
>>>> -- >> 	>>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
>>
>

-- 
Jay Lozier
jslozier at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/87e3a896/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/87e3a896/attachment-0001.png>