Slashdot Mirror
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.
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.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Do not look into laser with remaining eye.
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.
If you are not allowed to question your government then the government has answered your question.
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.
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.
.NET - with 32 flaws/MB (9.7 critical flaws/MB)
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)
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)
"First they came for the slanderers and i said nothing."
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.
>> 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.
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.