Every Programmer Should Know About These Insecure Programming Languages

By Kimberly Cook |Email | Apr 13, 2019 | 25395 Views

WhiteSource review of programming language security errors reveal which languages have the most security holes. The winner? C. But that's only the start of the story.

From top to bottom, technology is riddled with security errors. At the lowest level, we have hardware errors such as Intel's Meltdown and Spectre bugs. Just above those, we have programming language security holes, and boy, do we have a lot of those!

WhiteSource, an open-source security company, recently did a study of open source security vulnerabilities in the seven most widely used languages over the past decade. To find the bugs, the company used its language security database. This contains data on open-source vulnerabilities from multiple sources such as the National Vulnerability Database (NVD), security advisories, GitHub issue trackers, and open-source projects issue trackers.
Here's what the company found: The most insecure languages are C, Java, JavaScript, Python, Ruby, PHP, and C++. There are no surprises. 

There's also no surprise as to which language had the most security bugs. That's C, by a wide margin. Nearly 50 percent of all reported vulnerabilities were in C.

As  Kees "Case" Cook, Google Linux kernel security engineer, said recently: "C is a fancy assembler. It's almost machine code." In addition, "C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure."

But, WhiteSource argued: 
This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like OpenSSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open-source vulnerabilities in C.
They have a point. But having programmed and fought with C for decades now, I have found it really is way too easy to make terrible security blunders in C. For example, C contains a great deal of undefined behavior, which leaves all kinds of nasty possibilities open.

C++, however, has the "honor" of having the most high-severity vulnerabilities in the past five years. Buffer errors, which have long plagued C, are also now being discovered often in C++

That said, JavaScript, perhaps the most popular language, is also the only one that saw a "continuous rise in the number of vulnerabilities in the past 10 years."

Before making too much fun of JavaScript, those results, WhiteSource points out, are misleading. Most of JavaScript's Common Weakness Enumeration (CWE)s  are Path Traversal and crypto security holes from JavaScript packages, which are barely used, maintained, or supported.

So, why are they -- and other language problems -- showing up? New automated programs, such as Source Code Analysis Tools, are spotting vulnerabilities, which otherwise would have been overlooked.

The one language which has been showing well on security holes, is -- drumroll, please -- Python. Yes, good old -- often made fun of -- Python.

Nearly all languages share some CWEs. Two CWEs are found in 70 percent of the most common languages: Cross-Site-Scripting (XSS), aka CWE-79 and Input Validation, otherwise known as CWE-20.

Other CWEs that show up a lot are: Information Leak/ Disclosure (CWE-200), Path Traversal (CWE-22), and CWE-264 Permissions, Privileges, and Access Control. The last is being displaced recently with its more specific, close relative -- Improper Access Control (CWE-284).

But is C really the worst and Python the best? WhiteSource thinks that's much too simple a conclusion: "While the game of 'my programming language is safer than yours' is certainly a fun way to pass time ?  finding the answer will probably not help you create the most innovative or secure software out there."

No, instead you should spend your time "staying on top of known open-source vulnerabilities and understanding the strong and weak points in the programming languages you and your team are using."

In the end, security is not about the languages, but how you use them.

Source: HOB