How Secure is Your Web Programming Language?

If I were a betting kind of guy, I’d bet that most developers don’t consider the inherent security of their chosen programming language(s) when beginning a new project. I know I never have, although the choice of language does affect my choice of development tools, and, as a software security consultant and Microsoft Developer Security MVP, I pay attention to that kind of stuff. However, because of a new report out from WhiteHat Security, "2014 Website Security Statistics Report," I’m thinking more about language security. (You have to register to see the full report, but you can decline the 30-minute demo of their products, and so far I haven’t been deluged with emails or phone calls from marketing people.)

The report is an interesting read once you get past the marketing fluff, although I’m not sure that I’m quite as enthusiastic about the content as I was when reading the post where I first learned of WhiteHat's report. Nevertheless, I was immediately hooked after reading the first paragraph:

Whenever beginning a new software project, you have to make a choice: what programming languages or development frameworks to use? While it would be nice to select the most secure software stack at the start of a project, more often this decision is made for different reasons and security is commonly an afterthought.

Of course, it’s certainly the case that security would be an afterthought, but it's fairly understandable given that developers and teams typically have specific tools they like to use, and if they know a certain language best, that language is going to get the project built the faster and more efficiently. The report shows that the fastest and most efficient language isn’t always the most secure, and as attackers get increasingly clever, security needs to become a bigger consideration when starting a new project.

WhiteHat's report doesn’t come up with a ranking of languages by overall level of security, which I doubt would be doable in a way that works for most developers. What the report does do, however, is much more interesting. WhiteHat examines a number of security vulnerabilities—such as cross-site scripting, SQL injection, and URL redirector abuse—and calculates a number of metrics for various languages. For example, the report contains a table with the percentages of specific vulnerabilities for each language. Not surprisingly, cross-site scripting and information leakage are the top two vulnerabilities across the board.

The report gives the reader a high-level view of the methodology and data used to reach their conclusions, though certainly not with the rigor that you’d find in a typical peer-reviewed academic paper. But the report provides enough detail to understand what WhiteHat did. I’m not qualified to assess the validity of their methodology because I’m not familiar with their security monitoring tools. One factor they did consider, however, struck me as questionable: the median number of days that issues were open in a website.

The next data set we examined was the average number of days vulnerabilities remained open. Vulnerabilities go unfixed for many reasons and it begged the question as to whether there was anything to be learned from studying the length of time vulnerabilities were open in each of the languages.

Begs the question indeed. Unsurprisingly, the report found that classic (archaic?) ASP vulnerabilities stayed open for the longest period—139 days— followed by PHP with 129.5 days, and Java with 90.9 days. Other languages fell off rapidly from that point. This doesn’t make sense to me. What does the slowness of fixing security vulnerabilities have to do with the inherent security of the language? I suppose that the difficulty of fixing vulnerabilities is an issue, as well as the support of the language vendor or open source group. I suspect, though, that a large part of what is happening, at least with ASP, is that projects built with that language are older and likely to get less attention even when security problems are found.

The report is also a bit limited, including only ASP, ColdFusion, .NET, Java, Perl, and PHP. Those languages are, however, the heavyweights of the web development world, so they are probably sufficient for this kind of analysis. I can see, though, that this report would be a disappointment if your tool of choice isn’t included.

Potential flaws in the report aside, it is an interesting and thought-provoking read. Whether you agree with the results, the issue of the inherent security of your favorite languages is likely to become a more important consideration over time.