The Top Programming Languages That Spawn the Most Security Bugs (softpedia.com)

An anonymous reader writes: Veracode has put together a report after static analysis of over 200,000 apps, and its results show that Classic ASP, ColdFusion, and PHP generated the most security bugs in scanned applications. Ignoring the first two, which are almost extinct languages, PHP, used for Drupal, Joomla, and WordPress (which recently announced it runs a quarter of the Internet) is the programming language with the most security woes.

Comments

normalized?

[Anonymous Coward]

The Internet is a lot bigger now, so you'd expect more discovered PHP bugs than ColdFusion bugs.

Coming up next, there are more operating systems written in C than Fortran, so you will find more root privilege escalations in C than Fortran.

Self-fulfilling prophecy?

[mindmaster064]

It's pretty obvious the most common language is going to have the most apparent bugs and the most security woes because it is the one that is most used to solve the majority of problems. It also will be the most likely for hacker and bad people to be using as well as working to exploit as it is the language that they are most familiar with. Every language is going to have security issues it's what happens with the running application when it faults that matters, and that is likely within the control of the developers even when the language and library authors are contributing to the issues. Really, the number one "cause for exploits" is trusting input that shouldn't be trusted -- and that's that same problem for nearly any language... It has nothing to do with PHP!

Re:Self-fulfilling prophecy?

[paulpach]

There is more to it than simply being popular. Consider a case where you want to output data that the user posted in a form. The obvious way to do it in PHP is this:

Hi <?php echo $_POST['name']; ?>.

In fact up until a few years back, the php tutorial had code like this.

This is vulnerable code, the values posted may contain javascript, and the browser would execute it happily. If you are displaying content that other people posted, then a malicious user can easily exploit this code to hijack other users sessions. This is known as XSS (Cross site scripting), and it is one of the most common vulnerabilities in PHP code.

The secure way is this:

Hi <?php echo htmlspecialchars($_POST['name']); ?>.

A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else. For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value. In the name of convenience PHP is plagued by questionable design decisions like this. register_globals was on by default up until php 4.2, it is incredibly easy to write sql injection vulnerabilities in php if you are not paying attention, etc.

Re:Self-fulfilling prophecy?

[hey!]

While I strongly agree with the argument that PHP's large target footprint has something to do with its reputation for insecurity, I can't help but wonder whether the architectural similarities of typical PHP, ColdFusion and ASP.NET have something to do with the tendencies of some programmers to produce vulnerable code with them. If you squint, they all have a strong family resemblance to each other: you mix language-specific procedural markup with HTML, which is processed on a server and returned as plain HTML to the browser.

Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things so they show students the simplest way of producing a particular result -- not the way that a proficient programmer should produce that result. The message is "look at how easy it is to make a dynamic website with X!" The details of what you need to do to do things like sanitizing input really clutter that message up; especially in the case of these template-y languages where one of the chief selling points is that they're incremental on top of the HTML you need to know anyway.

It's interesting to contrast something like these systems to JSP, which can be used in exactly the same way except that programmers are taught early on that this "model 1" approach is for wimps who can't handle MVC. Java web apps tend to be grossly over-architected; PHP web apps -- at least the ones I've looked at -- tend to be under-architected, with lots of code replicated across many files which should be centralized in some kind of library. That's the second reason I can think why PHP apps might tend to be insecure: under-designed systems mean you have more places where you have to implement some design policy, or where a "temporary" bit of code that does something like build a SQL query from unchecked user input might slip through into production code. It's not the fault of the language per se; it's programmers reproducing the simplest way they were taught to do something over and over again rather than taking the time to refactor their work so that maintaining and securing it is a manageable task.

The third reason I can think of is that these kinds of systems are so easy for someone who doesn't know what he's doing to tweak in the field. I've done it myself; if you have a basic knowledge of HTML, have ever used a programming language, and know how to use "grep" you can find the bit of PHP that produces a particular output and tweak it to your liking without being a PHP programmer. That means that code that ships secure might not remain so in the field.

Anyhow, I don't know enough about PHP per se to say whether it is inherently insecure in some way, but what I've seen leads me to think that some of the problems at least may be an unwanted side effect of ease of use and learning. There's a world of difference between a PHP system generated by a skilled and conscientious programmer and someone who knows a little HTML and picks up a little PHP to add to that. Fortunately this kind of hacked-up HTML website is looking increasingly archaic these days; if you look at RESTful PHP code it looks pretty much like RESTful interfaces done in any other scripting language. It doesn't have the sprawl I tend to associate with PHP web apps.

And that's surprising ... how?

[Opportunist]

Especially for PHP you will notice that it is the first, if not the only, language people pick up when dealing with scripting for web pages. ColdFusion always smelled a bit like a web designer tool to get some kinda-sorta interactivity into their designs rather than something a programmer would willingly pick up, and I don't know of anyone who seriously learned programming and didn't give ASP a wide berth.

So what you have there is three languages that are predominantly used by people who cannot program sensibly.

In other words, you are dealing with the usual woes of cargo cult programming and copy/paste code. Code and snippets, copied and gobbled up from whatever sources there are on the net, sample code and code Q&A pages that are slapped together and adjusted to fit the needs. Primary concern: It should work. Security? Doesn't even enter the picture. Not even as an afterthought.

That this results in security bugs is a given.

What's a "programming language"?

[david.emery]

Are "iOS" or "Android" the same as "PHP" or "C++"? I didn't hand in my personal informatoin to get the full study, but the stuff shown on this story's link pegged my bs-meter. Also, I'd hope there's a discussion of 'number of occurrences,' finding 10 bugs, 8 of which are null pointer dereference, should be different from finding 10,000 bugs where 'only' 7,500 of them are null pointer dereference.

And wouldn't it be even more useful to know which languages generate the least number of bugs, per line of code?

Re:What's a "programming language"?

[tjarrett]

I'm an author of this report, so thought I'd offer some feedback.

First, the iOS applications that Veracode scans are written in Objective C (and probably some C or C++). And the Android apps are written in Java. (Yes, you can write iOS and Android apps using portability frameworks like PhoneGap; we separate those findings out into a separate category.) We used iOS and Android as shorthand so that (a) readers would more readily make the connection with what ObjectiveC meant, and (b) we could separate Java used in Android, which has a distinctive risk landscape, from Java used in other applications.

Second, we choose to report on application prevalence, or the number of applications showing at least one of the vulnerability, rather than number of vulnerability occurrences. The application prevalence metric is more meaningful when talking about the overall risk of a large number of applications. There is value in the vulnerability prevalence metric, when it comes to planning remediation effort, but for this study we focused on the former.

Third, we do report average flaw density metrics in the appendix of the study, along with a discussion of some of the limitations of this metric. I suggest reviewing the actual study (it's only about 20 pages) and then posting any additional questions.

Thanks for the questions and keep them coming.

Re:What's a "programming language"?

[Rei]

They use labels like "Objective C (iOS)", which the article is just shortening to "iOS". Also they report errors as "number of errors per megabyte of source code".

Wish they'd broken down C and C++, they're very different languages in terms of how people typically develop them (non-automated vs. automated memory management). Instead they grouped them together and called them just "C++".

Sad that injection bugs are still so prevalent. Kind of makes me wish that standards for different languages would refuse to accept normal strings as arguments to anything that "executes a statement" (SQL, shell commands, etc), and instead require a custom command-string type/class which does not allow straightforward concatenation (making developers explicitly have to convert types if they want to concatenate, maybe with a conversion function name like "useUntrustedString" or somesuch), with the error message if they try to concatenate without explicit conversion pointing out not just that concatenation is banned, but stating why it's banned. Maybe something like that would finally get people to start using proper parameter substitution...

Reason for this

[xxxJonBoyxxx]

If this was from a dynamic scanning company, I would have suspected these results would occurred because that code often run in environments often configured to show web users raw error output, such as "your database call failed - here's what I tried so you can tune your SQL injection attempt appropriately."

[rant] In general, I've found that the utility of "dynamic" (or pentesting) web scanners has dropped precipitously lately as web apps have pushed their presentation out to Javascript apps (making it easier to probe a finite set of web services with standard testing and fuzzing tools) and almost all new environments are set to display terse "got error - now fuck off" messages to end users (if not just a redirect back to the app's home page) if a probe generates an error (that would have generated useful output 10 years ago). [/rant]

  >> Ignoring the first two

This is a horrible assumption to make. I remember I looked at bringing Veracode in house specifically because I had a multi-million line legacy web app written in "classic ASP" that powered several hundred million dollars of annual purchases.

The problem is not the language, it is the coders

[gweihir]

You can write secure code in any almost any language (unless the run-time system is insecure, see for example the history of Java), and you can write insecure code in any language (yes, even in Rust, Swift and Go and other newfangled but not really better hype-languages). The difference is not the language. The difference are the people doing architecture, design and implementation. If some languages have more security problems, that is primarily because these languages attract less competent coders.

Incidentally, absolute numbers are irrelevant. What we need is issues per application.

Re:PHP is Fine

[TWX]

The problem is the users, PHP is so ridiculously easy to write it leads to people making horrible insecure "awesome" webpages.

I'll let you in on a little secret, the problem is always the users, regardless of technology. That's why some disciplines have separate security tracks from their development or administration tracks, because the concepts run completely contrary to each other. Development is there to provide access. Security is there to prevent access. At some point the two need to come to a compromise, but trying to get developers to do security is about as useful as trying to get security professionals to do development.

Re:Are all ten of them Java?

[tompaulco]

Just wondering.

Java is the 4th highest, with about 2% of the flaws found being Java. I'm really shocked that Java shows up higher on the list than Javascript. If ever there was a language where people copy and paste somebodiy's working code and try to mangle it to work for their own purposes with no understanding of the actual language or security thereof, it is Javascript.

Managed languages

[johannesg]

So much, then, for managed languages. I thought managed pointers and garbage collection were supposed to free us from all those ills, but evidentally not.

Shame that further down they perpetuate the myth of the C/C++ language. That language doesn't exist - it's either one or the other. In C you'd use raw memory pointers if you wanted to pass a buffer around, making it easy to access it beyond its boundaries. In C++ you'd pass a buffer object that knows its own size, and either dynamically resizes or at least throws an exception on an illegal access.

Because C and C++ have such vastly different approach to the same problem I'd love to see C and C++ split out.

Re:Meaningless conclusion.

[phantomfive]

Something like 75%-80% of the web runs on php (Wordpress, for example.) Naturally if you examine a large number of sites, most of which run on php, you're going to see more security problems coming from sites that run on php.

Seriously man? You don't think the researchers thought of that? If you had even clicked on the article, you would know that they did.

In any case, here is the full list:

Classic ASP - with 1,686 flaws/MB (1,112 critical flaws/MB)
ColdFusion - with 262 flaws/MB (227 critical flaws/MB)
PHP - with 184 flaws/MB (47 critical flaws/MB)
Java - with 51 flaws/MB (5.2 critical flaws/MB)
.NET - with 32 flaws/MB (9.7 critical flaws/MB)
C++ - with 26 flaws/MB (8.8 critical flaws/MB)
iOS - with 23 flaws/MB (0.9 critical flaws/MB)
Android - with 11 flaws/MB (0.4 critical flaws/MB)
JavaScript - with 8 flaws/MB (0.09 critical flaws/MB)

Re:Are all ten of them Java?

[Z00L00K]

The report only concerns security bugs, not all bugs. Most security issues with JavaScript are likely to have been hammered out now.

But JavaScript do fail from time to time on web pages, especially if there's a web page that do something that was permitted in an earlier version but not permitted any longer due to a security issue with that functionality. Another headache with JavaScript that most programmers today have rectified is browser differences.

Some browsers have taken in functionality from competing browsers to ensure compatibility so some issues with JavaScript have been resolved that way as well.

Java libraries - they are good, but also a curse since you can't ensure that you get everything right with the library functions in all cases. Experienced programmers may have their own library of JavaScript functions to use when they make their web stuff.

Re:The problem is not the language, it is the code

[xxxJonBoyxxx]

>> above will allow you to take the user entered name and put it into a SQL query without fear of little Bobby Tables wrecking havoc with your systems

[FACEPALM/] That's not even "checking user input" (i.e., making sure the user submitted an expected response) - that's "mindless scrubbing of a single naughty character."

Please send me a couple of the URLs where your apps live and I'll just go get the rest of I want from there.

Re:Are all ten of them Java?

[allcoolnameswheretak]

Java actually compares favorably against C# and C++ when you rank it based on the number if critical flaws:

1. Classic ASP - with 1,686 flaws/MB (1,112 critical flaws/MB)
2. ColdFusion - with 262 flaws/MB (227 critical flaws/MB)
3. PHP - with 184 flaws/MB (47 critical flaws/MB)
4. .NET - with 32 flaws/MB (9.7 critical flaws/MB)
5. C++ - with 26 flaws/MB (8.8 critical flaws/MB)
6. Java - with 51 flaws/MB (5.2 critical flaws/MB)
7. iOS - with 23 flaws/MB (0.9 critical flaws/MB)
8. Android - with 11 flaws/MB (0.4 critical flaws/MB)
9. JavaScript - with 8 flaws/MB (0.09 critical flaws/MB)

I think there is something wrong with their test method, skewing the JavaScript results.

Re:Are all ten of them Java?

[tjarrett]

An important clarification: as the report states, during the period from which this data was drawn, Veracode only supported analyzing mobile JavaScript applications (mobile applications built using cross-platform JavaScript based frameworks like Titanium and PhoneGap). Since this period we've added support for analyzing both JavaScript in the web client (e.g. JQuery based applications) and on the server (Node.js based applications), so the results should be interestingly different next time around. But this limited JavaScript support is a reason that we didn't seek to draw any broad conclusions based on the language in this study.