The security of the most popular programming languages

MrGuvernment

MrGuvernment

Fully [H]
Joined
Aug 3, 2004
Messages
21,812
http://www.net-security.org/secworld.php?id=16694

Suprised to only see Java with so little, or at least so close to .net, now is this from the front side of the java it's self, this obviously doesn't include vulnerabilities that coders themselves cause by bad coding..


whitehat042014.jpg


new WhiteHat Security report takes a deeper look into the security of a number of the most popular programming languages including .Net, Java, ColdFusion, ASP and more.



"Deciding which programming language to use is often based on considerations such as what the development team is most familiar with, what will generate code the fastest, or simply what will get the job done," said Jeremiah Grossman, founder and iCEO of WhiteHat Security. "How secure the language might be is simply an afterthought, which is usually too late."

"As an industry we lack sufficient security data that teams can rely on in the language selection process for their project," continued Grossman. "This report approaches application security not from the standpoint of what risks exist on sites and applications once they have been pushed into production, but rather by examining how the languages themselves perform in the field. In doing so, we hope to elevate security considerations and deepen those conversations earlier in the decision process, which will ultimately lead to more secure websites and applications."

WhiteHat researchers examined the vulnerability assessment results of the more than 30,000 websites to measure how the underlying programming languages and frameworks perform in the field. With that information, the report yields key findings around which languages are most prone to which classes of attack, for how often and how long as well as a determination as to whether or not popular modern languages and frameworks yield similar results in production websites.
Click to expand...

New vs. legacy languages

To lay the foundation for the research, the team first examined the volume of languages in the field, and found, unsurprisingly, that .Net, Java and ASP are the most widely used programming languages at 28.1%, 25% and 16% respectively. Legacy programming languages that have been around for decades, PHP (11%), ColdFusion (6%), and Perl (3%) rounded out the remaining field.

The popularity and complexity of .Net, Java and ASP, mean that the potential attack surfaces for each language is larger; as such, 31% of vulnerabilities were observed in .Net, 28% were found in Java and 15% were found in ASP.

From there, researchers had these key observations:
There was no significant difference between languages in examining the highest averages of vulnerabilities per slot. .Net had an average of 11.36 vulnerabilities per slot. Java was found to have an average of 11.32 and ASP came in at 10.98.
The bottom of the spectrum, or the most "secure," also showed no significant difference between languages with the lowest averages of vulnerabilities per slot. Perl was observed as having 7 vulnerabilities per slot. ColdFusion was found to have the fewest with an average of 6.
From a vulnerability class perspective, the research team made these discoveries:
Cross-Site Scripting regains the number one spot after being overtaken by Information Leakage last year in all but one language. .Net has Information Leakage as the number one vulnerability, followed by Cross-Site Scripting.

ColdFusion has a rate of 11% SQL Injection vulnerabilities, the highest observed, followed by ASP with 8% and .NET 6%.
Perl has an observed rate of 67% Cross-Site Scripting vulnerabilities, over 17% more than any other language.
There was less than a 2% difference among the languages with Cross-Site Request Forgery.
Many vulnerabilities classes were not affected by language choice.
Remediation remains a key factor

"We were somewhat surprised to find that languages that have been around for decades were actually able to keep pace, with more modern languages when it came to remediation of some vulnerability classes," said Gabriel Gumbs, director of solutions architecture for WhiteHat Security who also led the research team on this project. "For instance, Perl bested the pack when it came to remediating XSS vulnerabilities, which was the most prevalent vulnerability across all languages. Likewise SQL Injection had a 96% remediation rate in ColdFusion applications and every single abuse of functionality vulnerability found in ColdFusion sites was remediated."

Other interesting remediation statistics:
ASP is remediating at the same rate as the other languages, focusing on mission critical vulnerabilities.
Perl remediates 85% of all Cross-Site Scripting vulnerabilities, the highest rate among all languages but only 18% of SQL Injection.
Net and Java have the same remediation rate of SQL Injection at 89%.
ColdFusion remediates 100% of its Abuse of Functionality vulnerabilities, 96% of its SQL Injection, and 87% of Insufficient Transport Layer Protection vulnerabilities.
Industry favorites

"Often times when we have conversations with customers or their development teams about why they believe that practicing secure coding is so challenging, they will tell us that it is because their applications are often made up of 'a little bit of everything'," said Gumbs. "In our research, however, we found that organizations tend to have a significant amount of one or two languages with a very minimal investment in the others."

Although the team found that no industry has an even breakdown, there are trends amongst industries, when it comes to language choice:
Financial Services has the highest number of ASP sites by count, by almost 3-to-1.

83% of Gaming Industry sites written in PHP.
49% of the Banking Industry applications were written in Java & 42% in .Net.
32% of Manufacturing sites leveraged Perl as their language of choice.

The Technology sector wrote 35% of their sites in PHP.
"Ultimately we believe that just as language choice begins at the architecture and design stage of application development, security must begin here as well," said Grossman. "Understanding the impact of those decisions early will help address the management of the risk later on. Furthermore, ensuring that software is tested in all phases of development - including code reviews of web services – all the way through until the application is decommissioned is critical. We will not achieve a truly secure Web until this becomes standard operating procedure for all applications across the board."
Click to expand...
 
It's kind of pointless as it doesn't break the stats down by version. Someone creating a web application is unlikely to use really old releases, and vulnerabilities clustered around legacy releases won't tell you much about the current security climate. The article delivers what it states, but the numbers don't mean much when mashed together. The .NET numbers actually don't surprise me because there are so many low-skill programmers developing on it.

It's a "headline" article.
 
Most of Java's headline grabbing security vulnerabilities are actually vulnerabilities in the implementation of the sandboxing mechanism used by Java browser plugin and have nothing to do with the language itself.
 
It's not clear to me where they get the idea that .NET is a programming language.
 
wonderfield said:
It's not clear to me where they get the idea that .NET is a programming language.
Click to expand...

It's a common (though yes, ambiguous) thing people say. Some people seem to be referring to C# (on .NET), others seem to be referring to any of the many languages which run on the .NET framework. Certainly, they're not the first to have done such a thing.
 
Dogs said:
It's a common (though yes, ambiguous) thing people say. Some people seem to be referring to C# (on .NET), others seem to be referring to any of the many languages which run on the .NET framework. Certainly, they're not the first to have done such a thing.
Click to expand...

Indeed, it would be like referring to JVM when you really meant to refer to Java. Lots of languages run on the JVM, Java is just one of them.
 
wonderfield said:
It's not clear to me where they get the idea that .NET is a programming language.
Click to expand...
Neither is "ASP". :p It's programmed in whatever active scripting language the user chooses.

It might have been more accurate to describe the groups as platforms used in the front facing portion of web applications. It's a lame study.

devman said:
Most of Java's headline grabbing security vulnerabilities are actually vulnerabilities in the implementation of the sandboxing mechanism used by Java browser plugin and have nothing to do with the language itself.
Click to expand...
Most of the headlines on Java security have to do with the large number of vulnerabilities patched at a time, and most have nothing to do with sandboxing breaches. That is certainly a route of exploiting those vulnerabilities outside of running Java applications locally or on servers, but the vast majority of security problems are in the language implementation and libraries. Oracle is light on details, but this is just one critical update: http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html#AppendixJAVA It's ridiculous.
 
Last edited:
If you were to compare Java to C, e.g., I think as a language Java is more secure. I'm just speaking of the language here, not necessarily the implementation of the foundation classes (which ultimately tap C code). In C, even the best programmers have a lot of opportunities to slip up.

If you look at the Heartbleed bug, that kind of mistake would be very difficult to make in Java.
 
pxc said:
Most of the headlines on Java security have to do with the large number of vulnerabilities patched at a time, and most have nothing to do with sandboxing breaches. That is certainly a route of exploiting those vulnerabilities outside of running Java applications locally or on servers, but the vast majority of security problems are in the language implementation and libraries. Oracle is light on details, but this is just one critical update: http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html#AppendixJAVA It's ridiculous.
Click to expand...

I sampled the top 5 exploits and then sampled 5 more arbitrarily picked ones from that list all of them were applet/sandbox vulnerabilities. I'm not going to go through the entire list just to find out they are all or mostly sandbox vulnerabilities, but I'd be happy for you to point out a few. Do not get me wrong, they certainly do exist, and there have been a good number of critical ones.

An example of a non-sandbox vulnerability was someone found a cool infinite loop in Double.praseDouble(double) method built-in to the JDK that created a Denial-of-Service attack on common application servers. To trigger it you had to give it a specific string, this would often be injected in an HTTP header that would be handled by a servlet container. A good number Java CVEs are about sandbox exploits.
 
Last edited:
jwcalla said:
If you were to compare Java to C, e.g., I think as a language Java is more secure. I'm just speaking of the language here, not necessarily the implementation of the foundation classes (which ultimately tap C code). In C, even the best programmers have a lot of opportunities to slip up.
Click to expand...
Sure, Java — as a language — is more secure. The typical buffer overruns you see in unchecked C arrays, for instance, can't really happen in plain old Java (can they?). That said, they can occur in a Java VM.

You're always at the mercy of something. You could argue that Java largely shifts the burden of security away from users and into the runtime, but that's certainly done no favors for Sun/Oracle.
 
wonderfield said:
Sure, Java — as a language — is more secure. The typical buffer overruns you see in unchecked C arrays, for instance, can't really happen in plain old Java (can they?). That said, they can occur in a Java VM.
Click to expand...
They can occur in Java, too -- just not quite as readily. ByteBuffer, for example, enables HeartBleed-style overruns if you don't clear it between uses.

Meanwhile, I can't figure out what "mean number" means here. "mean" is an arithmetic average ... an average over what population or set of samples?
 
mikeblas said:
Meanwhile, I can't figure out what "mean number" means here. "mean" is an arithmetic average ... an average over what population or set of samples?
Click to expand...

I've found lots of things to be peculiar about this 'article'/'study' and lots of unanswered questions. For example, this quote: "How secure the language might be is simply an afterthought, which is usually too late." Reading this article, I really get the impression that the individual is suggesting that we place significant weight on language security during the language selection process. While this seems novel, I can't imagine ever deciding to write a big web application in Perl (which only a small portion of our developers really use, and I'm not aware of any web applications we've written in it) rather than Java or ASP.NET (which many of our developers have a lot of expertise in) because Perl has 6 mean vulnerabilities instead of 11. I can only imagine that the extra resources we would spend on using a language we don't have a lot of expertise in and which doesn't have nearly as many libraries and frameworks for our particular purposes could be better used, even in the pursuit of better application security.

They're strongly advocating choice of language as a means of security, but I personally think things like developer competence, good development/testing methodologies, and security consciousness will get you a lot further. They say pick the language with the fewest vulnerabilities...I say know your language and what you're doing with it, and where things could or often do go wrong.

Like you mentioned, I too don't find 'mean number of vulnerabilities' to be particularly insightful either....Are these the mean number of vulnerabilities over time? Over particular versions/releases? Are they getting these 'vulnerabilities' from the same place or different places? What about considerations like severity? If one language has 20 vulnerabilities, but they're all relatively small and difficult/impractical to actually exploit, and another one has 5 very severe, very easy to exploit vulnerabilities, which language am I supposed to view as more secure? If I were to look at these vulnerabilities, how many of them are actually relevant to me? If most of Java's vulnerabilities are in Swing, and I'm not using Swing, I could end up deterred from using other Java technologies and instead using something with far more vulnerabilities that are relevant to me.

Maybe some of these considerations were taken, and 'unlocking' the full report would answer some of my questions...but I don't feel particularly compelled (based on what I've seen of this report so far) to pursue that.
 
Dogs said:
Maybe some of these considerations were taken, and 'unlocking' the full report would answer some of my questions...but I don't feel particularly compelled (based on what I've seen of this report so far) to pursue that.
Click to expand...
Which is too bad, because the web journalism summary of the report is very likely poisoning your opinion of it. (But I completely agree with you.)
 
You must log in or register to reply here.
Back
Top