Slashdot Mirror
Which Programming Language Has The Most Security Vulnerabilities? (techrepublic.com)
An anonymous reader quotes TechRepublic: To answer this question, the report compiled information from WhiteSource's database, which aggregates information on open source vulnerabilities from sources including the National Vulnerability Database, security advisories, GitHub issue trackers, and popular open source projects issue trackers. Researchers focused in on open source security vulnerabilities in the seven most widely-used languages of the past 10 years to learn which are most secure, and which vulnerability types are most common in each...
The most common vulnerabilities across most of these languages are Cross-SiteScripting (XSS); Input Validation; Permissions, Privileges, and Access Control; and Information Leak / Disclosure, according to the report.
Across the seven most widely-used programming languages, here's how the vulnerabilities were distributed:
- C (47%)
- PHP (17%)
- Java (11%)
- JavaScript (10%)
- Python (5%)
- C++ (5%)
- Ruby (4%)
But the results are full of disclaimers -- for example, that C tops the list because it's the oldest language with "the highest volume of written code" and "is also one of the languages behind major infrastructure like Open SSL and the Linux kernel."
The report also notes a "substantial rise" across all languages for known open source security vulnerabilities over the last two years, attributing this to more awareness about vulnerable components -- thanks to more research, automated security tools, and "the growing investment in bug bounty programs" -- as well as the increasing popularity of open source software. And it also reports a drop in the percentage of critical vulnerabilities for most languages -- except JavaScript and PHP.
The report then concludes that "the Winner Of Most Secure Programming Language is...no one and everyone...! It is not about the language itself that makes it any more or less secure, but how you use it. If you are mitigating your vulnerabilities throughout the software development lifecycle with the proper management approach, then you are far more likely to stay secure."
Coincidentally, WhiteSource sells software which monitors open source components throughout the software development lifecycle to provide alerts about security (and licensing) issues.
It is only really the default configuration of older PHP versions that make it so much more practically insecure. In reality, JavaScript should be higher up on this list, because some of it's innate behaviors are so badly designed they cause vulnerabilities that can't be mitigated in any way other than simply not using it.
I'd list all of the public and semi-public repositories that publish modules for automatic installation and update. These include pip, ant, maven, gradle, CPAN, and gems. The Java repositories used by ant, maven, and gradle tend to have unknown binaries and unknown provenance, with no reliable way to evactly recreate the published jar files. Ruby gems have a similar issue. CPAN and pip rely on upstream source code for local deployment or compilation but are also very vulnerable to their default download of the most recent version of any module, which may or may not interact badly with other obsolete or updated modules. It's why many operating systems publish packaged binaries, and it's why the "compile as needed" operating systems cannot be stable and _cannot_ be thoroughly secured.
Of course the programmer creates security holes by how they use the language. But in PHP (more the case in older versions) some "features" gives a sense of security while they actually don't. 'addslashes()' vs 'mysql_real_escape_...' for instance ; 'strpos' that returns 'false' if not found (instead of -1) so in a 'if' the programmer might misses a position at 0... Local functions are actually not local... etc... etc... All of that is Ok when you're used to the language, but they're just counter-intuitive traps that even a good programmer may fall into at the beginning.
Slashdot, fix the reply notifications... You won't get away with it...
I knowingly created a vulnerability in a single sign-on system that I implemented. I did it for expediency. But when I did, I spoke with my boss about it first, and then we all talked about it at a staff meeting to try to determine ways that it could be exploited. The two we came up with involved a bad actor who already had unrestricted physical access to a logged-in user's machine, or a bad actor who had reality-defying luck at guessing a UUID within a 24-hour period. In either case, the attacker couldn't gain access beyond the user they impersonated. It was decided that even though a vulnerability existed, successful exploitation was unlikely.
The point being, as you say, not all vulnerabilities are made equal. If you can determine the risk of exploitation, the value of the system being protected, and the cost of recovery from a bad action, and accept all of that, then maybe the cost of eliminating the vulnerability is greater than the expected cost of dealing with an exploit.
PHP has more than a dozen different ways to connect to a database. PHP has a long history of glomming on new APIs, but never deprecating the old, even when shockingly insecure. This is especially bad for PHP because most of PHP's user base are low IQ Wordpress extension hackers who are not qualified to be making security decisions on their own.
The same is true of C programmers though, far too many of them don't understand the language and just hack stuff together to fulfil the contractual obligations and then disappear.
Contract work is a particular problems. There was a study recently, sorry I lost the link, where they put out contracts for a basic login page. Most of the developers didn't bother storing the password securely at first, then when asked managed to botch doing it. Contract work encourages minimum effort and throwing unsuitable libraries at problems, and often the person checking for completion doesn't understand the security issues.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Care to explain?
Not a python programmer, but in any language I know, writing "x=y" instead of "y=x" results in silent data loss. The wrong variable is overwritten, loosing the data we wanted to copy into the other variable. And there is nothing the language/compiler/interpreter can do about that - either statement is valid, the compiler can't know we made a mistake unless one of the variables are read-only. Which usually isn't the case. And the language does not have a AI strong enough to guess what we wanted. If it had, it could write the program without us.
C, C++, assembly, pascal, scripting languages - they all fall for this. Garbage code in, garbage results out. Object orientation and read-only variables sometimes offer a little protection, but there is no help when both variables are local and writeable. Warnings about "assigning a value that never get used" catches a few of these, but often enough the value has been used so this trick cannot be relied on. (And the logic is too weak and won't catch it anyway if we're overwriting "x[i]" instead of just "x".)
In what language does writing "x = y" when you meant "y = x" not lose the value of x, which you intended to keep?
Everything *MUST* *BE* unit-tested for type-correctness
While I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.
I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.
(The code I mention created a set of pure interfaces, then instantiated them and called their methods... and they worked! There was machinery that intercepted the instantiations and chose appropriate concrete types. Essentially it was a particularly opaque dependency injection framework. Think Guice, if you're familiar with that, but with absolutely nothing in the code to indicate that dependency injection was happening.)
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.