Security Statistics Report 2014 – White Hat

An end to the war of languages… maybe.

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.

  • The software stack decision is commonly based upon parameters such as:
  • What the development teams are most familiar with.
  • The current market momentum around the latest and greatest technology.
  • What will generate code the fastest and can be maintained at a low cost.
  • The available talent pool as the project grows.
  • And of course, whatever gets the job done.

Your programming past, what language did you know better, will surely influence your decision. Your compromises can also include the security aspect, just because you’re comfortable in a certain circle of language, and you only decide upon them. If you try looking from a different angle, it’s actually quite normal because these languages are the most promoted. As the community grows, languages are becoming more and more popular and have their shiny moment. The language takes bigger and bigger leaps forward, but so it’s probability of having security flows. Most probably, languages like Java, PHP, C# are not more secure than other languages.

Almost, most people consider that everything stays in the development process. You, as developer can code securely in a programming language, or conversely, insecurely. We know information security, and in particular application security, is littered with conventional wisdom and lacks foundational data. But we must ask ourself, are the flows usually hidden in the coding process or in the laying foundation of it’s core functions?

Whitebelt has published a security report that tries to determine the balance between what we think that matters to take in consideration, versus what we consider unimportant. The report is based on 30,000 websites that were security assed and many risk-prone areas were identified based to the data analysed.

The report hasn’t changed more than the previous, because even the security aspect has started to be closely taken in consideration, also the number of computer users and web resources has drastically increased. The numbers remained mostly the same, but the financial loss increased.

The process can be flawed from the start

In the architectural reviews, people of valuable knowledge who can be considered professionals, often take decision on the high-level, missing the important pieces with just a bit. Considering a web application that’s going to be created from scratch, multiple users will make them take in consideration the involvement of sessions. These should be initiated, managed and destroyed in a secure manner, and also to determine that if these sessions are authenticated, they must begin as an encrypted authentication event to avoid session fixation. But the missing point from the decision-making process is the absence of researching in what is the language that provides the handles session most securely. How difficult is to shrink the gap between the first on the list and the new one?

For example if users can send messages on to each other, XSS is a risk and has to be taken in consideration. But how well-equipped the chosen technology will be to protect against XSS. Is it up-to-date to the latest XSS variations?

Fundamentals:

.Net was the most widely represented language choice with 28.1% of web applications using the framework, followed by Java at 24.9% and ASP at 15.9%. However, the number of URL crawled was in Java’s favour:

Screen Shot 2014-09-18 at 12.29.10 AM

Mean number of vulnerabilities in each language

Screen Shot 2014-09-18 at 12.38.11 AM

Vulnerability classes

  • 10.59% of ColdFuision sites had at least one SQL Injection vulnerability, the highest observed, followed by ASP with 7.67% and .NET 5.78%.
  • Perl sites had a 67% chance of having at least one Cross Site Scripting (XSS) vulnerability, over 11% more than any other language.
  • There was less than a 2% difference among the languages with Cross Site Request Forgery (CSRF).
  • Many vulnerability classes were not affected by language choice.

Language observations

  • ColdFusion has the best overall remediation rates at 74.3%.
  • ColdFusion is significantly affected by Abuse of Functionality vulnerabilities with 5.93% of all sites having at least one occurrence, five times that of other languages.
  • PHP had the lowest observed remediation rates.
  • PHP is significantly affected by Insufficient Transport Layer Protection vulnerabilities, at 4.13% versus an average of 1% of all the combined major languages (Perl, Java, ASP, .Net & ColdFusion).
  • Perl has the greatest remediation time of XSS, at 265 days to resolve.
  • Perl’s median remediation rate of CSRF is 23.8 days, three times faster than the next closest langague, PHP at 68.97 days. All other languages were over 100 days.
  • ColdFusion and PHP have fast remediation times when vulnerabilities are addressed: 50.5 and 47.5 days respectively.
  • ASP takes the longest to fix all vulnerabilities averaging 139.97 days. .Net averages 111.86 days and PHP rounded out the bottom with an average of 47.49 days.
  • ASP is remediating vulnerabilities at the same rate as other languages, but efforts are focused on critical issues.*

Industry observations

  • Financial Services, HealthCare and Insurance organizations had the highest numberof ASP sites by a 3:1 ratio.
  • 86% of Gaming industry sites are written in PHP.
  • 36% of Banking industry sites were written in Java and 55% in .Net.
  • 43% of Manufacturing sites leveraged Perl as their language of choice.
  • 35% of the Technology sector wrote their sites in PHP.

Average vulnerabilities

In a moment, we will return to exploring the security of software stacks. But first, knowing that there was no significant difference between languages with the highest averages of vulnerabilities per slot we took a step back to look at how each website performed as they are most often comprised of multiple technologies. The importance of knowing the security posture of your websites is, from a security perspective, more important than language choice.

Vulnerabilities per language

Now that we have examined the average number of vulnerabilities observed in websites we will drill down and explore the vulnerabilities found in each language and the possible significance of these findings.

We found that 31% of all vulnerabilities found were in .Net applications. It must be noted that there are more websites written in .Net than all of the other languages in the study and that there was no evidence to suggest that .Net is any less secure based on this data point. In fact, .Net sites have a tendency to be larger and more complicated, which is directly correlated with having a larger attack surface and consequently more vulnerabilities.

Java – by virtue of its popularity with its extensive standard library class and its familiarity among programmers – accounted for 28% of all the vulnerabilities found. Again, the number of applications written in the language along with the complexities of the websites has to be considered as a contributing factor.

Originally released almost two decades ago ASP totaled 15% of all the discovered vulnerabilities. Although lacking the complexities of modern frameworks, many of the same critical vulnerability classifications were found to be present, as we will explore.

Another popular server-side scripting language, PHP also accounted for 15% of vulnerabilities discovered. A language still popular with Retail, Technology, and Financial Services organizations, PHP sites do not have a tendency to be as large or complex as .NET or Java sites but still suffer from many of the same issues.

The percentage of vulnerabilities found among the remaining languages experiences a sharp drop off from this point. ColdFusion, another platform almost 20 years in existence, only accounted for 4% of the vulnerabilities, while Perl registered at 2%.

Median days open

By language

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.

ASP vulnerabilities were open for an median of 139 days, more so than any of the other languages.

PHP rounds out the top of the list with an average days open of 129.5 days. The numbers begin to significantly decline beyond Java, which had an average of 90.9 days open. The other languages were all under 45 days once we hit this drop off.

By class

Cross-Site Scripting in the PHP environment was open the least median number of days at 49. Perl and ASP respectively had XSS issues open an average of 184 and 135 days. .Net did not fare much better with XSS having an average number of days open of 126. Overall XSS appears to take a relative amount of effort regardless of the language class.

PHP stood out from the pack when looking at SQL Injection, with the languages instances of the vulnerability exhibiting the lowest average number of days at 6.8, closely followed by Perl, which had the issue open an average of 19.4 days. ColdFusion topped the list averaging 107.4 days of exposed SQL Injection vulnerabilities. ASP’s average number of days open for SQL Injection was not far off of the ColdFusion average at 97.5 days. .Net and Java fell roughly in the middle at 51.4 and 64.8 days respectively.

The vulnerability with the highest average number of days open was Weak Password Recovery Validation in ASP websites, while not the most damaging vulnerability by itself, this could speak to a number of things such as, complexities of the language itself, programming experience necessary, or simply that this vulnerability class is not a priority in that environment.

Days open of top 5 vulnerability classes

Screen Shot 2014-09-18 at 12.42.26 AM

 

Key findings:

  • ASP vulnerabilities remain open the longest at 139 days.
  • Cross-Site Scripting takes the longest to close in Perl taking 184 mean days.
  • ColdFusion has the largest average days open for SQL Injection vulnerabilities at 107 mean days.
  • Languages with the most security controls are taking the longest to remediate.

 

Vulnerability classes

Cross-Site Scripting (XSS)

XSS regained the number one spot for being the most common vulnerability, after being overtaken by Information Leakage last year in all but one language: .Net, which still has Information Leakage as the number one vulnerability, followed by XSS.

Stand-outs

ColdFusion has a significantly higher percentage of abuse of functionality vulnerabilities at 6% compared to Java, the language with the second highest percentage at 1%. ColdFusion does, however, boast a 100% remediation rate versus Java’s 78% remediation rate or abuse of functionality vulnerabilities.

ColdFusion also suffers from the greatest percentage of SQL Injection at 11%. ASP takes second place with 8%. Java had the lowest percentage of SQL Injection at 1%. Again we see ColdFusion with a higher remediation rate of 96% versus Java’s 89%.

PHP’s rate of Insufficient Transport Layer at 4.13% is the highest, exceeding Java by almost 4-times which came in second at 1.34%. Coupled with a low remediation rate of 52%, PHP applications are at a much higher risk of exposing sensitive information.

Screen Shot 2014-09-18 at 12.44.41 AM

 

Remediation rates

Progress measured

Remediation rate is the key accountability metric in any web application security program. Affected by many factors – including business functionality, complexity, and priority – the rate at which vulnerabilities are addressed is a key indicator of application security maturity. Likewise, languages are affected by unique factors as they pertain to remediation rates. Some languages have frameworks that make addressing different vulnerability classes less complex than others. The skill levels of the available programmer resources and the libraries used directly affect the security of individual languages.

Perl’s remediation rate of XSS vulnerabilities bested the pack boasting an 85% rate. When it came to addressing SQL Injection vulnerabilities on the other hand, Perl had the lowest remediation rate of 18%. Perl did have the lowest number of days open for SQL Injection, so it is apparent that when these vulnerabilities were addressed, they closed faster than any other language.

SQL Injection had a 96% remediation rate in ColdFusion applications and every single abuse of functionality vulnerability found in ColdFusion sites was remediated.

Legacy ASP sites exhibited remediation rates on par with other languages while suffering from large windows of exposure suggesting that there were strategic decisions being made regarding the maintenance and security of these sites. Classic ASP struggles from being developed at a time in the history of the web when the breadth of attacks were not what they are today, yet what we see here is a great amount of effort to keep pace with the remediation rates of modern frameworks.

There was no immediate data to suggest that language choice greatly affected remediation rates given that a language such as ASP is able to keep track while PHP lagged much further behind. The efforts to keep pace may be enough reason to retire these legacy sites, however more often this choice is based on the need for update functionality.

Recommendations

Language choice

Cross-Site Scripting is the one vulnerability that appears to be affected by language choice, however, regular assessments and focused remediation efforts can manage that risk. Language choice begins at the architecture and design stage of application development; security must begin here as well. Understanding the impact of those decisions early will help address the management of the risk later on. The practice of choosing languages based on business needs and functionality is not in question here; those factors are how our business derives revenue. However, we should not overly rely on frameworks to provide protection. More security controls in a framework tend to make it harder to remediate because developers don’t know how to fix it. Instead, solid coding practices and code review are your best tools. Ensuring that software is tested in all phases of development and including code reviews of web services as they are critical components to modern complex web applications.

Governance

Corporate Governance has long since spawned excellent IT governance frameworks. The inclusion of application security into your existing governance frameworks is vital for the reduction in the risk that is inherent in web applications. The application investment decisions should align with the strategic priorities of the information security group. If budget were no object this would not be necessary, however, budget is limited and security spending must be allocated to efforts that reduce as much risk as possible while balancing budgets.

Current governance frameworks can be over-arching and require a herculean effort to apply to your SDLC process. It is very important to not allow application security governance to exceed the amount of effort required to deliver a project. If a developer has to spend more time filling out request for change forms or your security department becomes inundated by the processes of application assessment, the teams will lose trust in the system and find ways around it.

When it comes to governance, one-size does not fit-all. This is why the frameworks are as large as they are. They are intended to serve as a guideline for all. The governance that you apply to your application security program must match your needs and requirements.

A risk-based approach

A risk-based approach is a management method for application security that relies on quantifying risk in dollars and cents as the main driver for security decisions. This approach cannot be applied during the language selection process, however, that choice is best made based on business needs and functionality.

The determined risk is then the probability and potential loss magnitude in dollars, represented by application vulnerabilities.

Once risk is quantified, meaningful comparisons can be made to drive decisions.

These decisions include:

  • Remediation decisions (to remediate an application vulnerability or not, and when to remediate)
  • Prioritization decisions (stack ranking of which vulnerabilities should be remediated first)
  • Resource decisions (opportunity cost to apply limited development resources to fix vulnerabilities)
  • Funding decisions (establishing business case justifications for web application security projects, how much budget to allocate towards web application security versus alternative security budgets)
  • Policy decisions (establishing policies for handling web application risk – remediate, mitigate, postpone, transfer, accept)
  • Exception decisions (e.g. when to allow exceptions to remediation SLAs, and for how long)

Screen Shot 2014-09-18 at 12.47.10 AM

 

About WhiteHat Security

Founded in 2001 and headquartered in Santa Clara, California, WhiteHat Security provides end-to-end solutions for application security. The company’s cloud website vulnerability management platform and leading security engineers turn verified security intelligence into actionable insights for customers. Through a combination of core products and strategic partnerships, WhiteHat Security provides complete application security at a scale and accuracy unmatched in the industry. WhiteHat Sentinel, the company’s flagship product line, currently manages thousands of websites – including sites in highly regulated industries, such as e-commerce, financial services and healthcare companies. For more information, visit www.whitehatsec.com.