[Dailydave] Boom! Loopcasts.

[security curmudgeon]

On Tue, 20 Aug 2013, Justin C. Klein Keane wrote:

:   I think it's irresponsible to label an entire language insecure, even 
: one like PHP, which is the favorite whipping boy of the security 
: community.  While it is accurate to say that PHP is an extremely 
: widespread, and easy to learn, programming language for producing 
: globally available always-on web applications, and that the popularity 
: and ease of PHP lend themselves to novice's producing insecure 
: applications in the language, it is not accurate to say that PHP itself 
: is insecure.  PHP based applications suffer just as many security flaws 
: as any other application.  Security, or lack thereof, is derived in 
: implementation.
: 
:   While we can make specific claims about security related attributes of 
: PHP, such as: PHP doesn't allow the programmer to make unchecked memory 
: assignments (i.e. no buffer overflows), we can't say that this makes the 
: language secure or insecure.  It is just as easy to produce an insecure 
: web application in Java, or ASP.NET, [4] as it is in PHP. Singling out 
: an entire language for derision doesn't really advance any conversation 
: of purpose.

If you look purely at vulnerabilities, as documented by vulnerability 
databases, that affect the language itself, as opposed to the applications 
written in them, then Dave's comment holds up.

- There are over 600 documented vulnerabilities in PHP itself.
- There are over 150 documented vulnerabilities in Ruby, but some of those 
  are third-party gems.
- There are over 40 documented vulnerabilities in GNU C Library (glibc).

Perl and Python are a bit trickier to quickly determine for me (like you, 
not spending much time on this). 

Just based on that alone, PHP has obvious deficiencies. Then throw in the 
poor coding practices of PHP developers and it's a mess. I am not going to 
speak to Ruby because it is a relatively new language compared to the 
others, and with the eleventy-billion gems, it is just begging to get bent 
over. We've recently seen a single researcher (Larry Cashdollar) show that 
Ruby gems frequently have trivial old-school vulnerabilities in them, 
demonstrating that even the newer languages haven't accounted for an 
entire classes of old vulnerabilities.

: posture.  If Immunity had a PHP based web forum compromise, and didn't 
: review the forum software before deploying it, the fault doesn't lie in 
: PHP, but with Immunity for not performing due diligence with respect to 
: the software.

By that logic, then it is never the fault of the software, always the 
fault of the organization.

Are you really suggesting we thrust that responsibility entirely on the 
end user?