WP The State of Web Application Vulnerabilities in 2016 | Imperva

Archive

The State of Web Application Vulnerabilities in 2016

The State of Web Application Vulnerabilities in 2016

Part of our job on the Imperva web application security team is supplying inclusive mitigation to new security vulnerabilities in web applications as soon as they become public. Imperva continually gathers information regarding new vulnerabilities from multiple sources—official databases, pen test tools, security mailing lists, social media, and payloads found in the wild. And because new security vulnerabilities are found each and every day, we have developed a rapid identification and delivery process that brings our web application firewall (WAF) customers protection from vulnerabilities as quickly as possible.

As we enter 2017, we look back at the past year in order to understand the changes and trends in web application security and assess the way Imperva is handling them.

Web Application Versus Non-Web Application Vulnerabilities

The first thing we reviewed is the total number of web application vulnerabilities (i.e. relevant to WAF customers) vs. non-web application vulnerabilities (i.e. irrelevant vulnerabilities to WAF customers). We define relevant vulnerability as a web application vulnerability that can be exploited remotely against a web application server. So, for example, XSS attack in a WordPress plugin is relevant, but a vulnerability in a desktop application is irrelevant and hence out of our scope.

From the data we gathered, it seems that although the total number of security vulnerabilities went up during the past two years, the number of security vulnerabilities relevant to web applications went down. One possible explanation of this phenomenon could be that web applications’ security is getting better thus it is more difficult to find relevant vulnerabilities. Given the huge amount of attacks we see on a daily basis we find the theory less likely.
A more likely explanation can be that this trend stems from a shift in the cyber security research focus that was influenced by changes in network-based consumption. For instance, a growing number of IoT devices, with a growing number of new security vulnerabilities, were introduced to the market with little or no security at all. Also, vulnerabilities in proprietary application code are not published through our data sources (i.e. SQL injection in a specific retail site, XSS in a specific search engine application, etc.).

Relevant Vulnerabilities by Priority

Another ever-present concern for Imperva’s application security team is determining the best strategy for reducing the time it takes to assess new vulnerabilities without compromising the quality of the evaluation and solutions provided.
Each new vulnerability, relevant or irrelevant, that is detected by Imperva is classified by an automated system into one of two categories:

  1. High priority vulnerabilities – these vulnerabilities are not necessarily relevant, but if exploited are posing high risk to the affected system. Our web application security team manually reviews and evaluates these vulnerabilities every day. If the vulnerabilities are relevant and can be mitigated, then a new virtual patch is released in order to protect our WAF clients against possible exploits.
  2. Low priority vulnerabilities – these are vulnerabilities that might be relevant but pose low risk in matters of impact, data integrity, and exploit effort. These vulnerabilities are marked for analysis for a later time.

Vulnerabilities Coverage

Another aspect we want to assess is the vulnerability coverage of Imperva’s WAF. Over the years we’ve noticed many times that a virtual patch that was released against a specific vulnerability can mitigate many other vulnerabilities. For example, blocking requests that are using some SQL injection technique would mitigate against SQL injection payloads in many other scripts and framework.
The virtual patches that were accumulated over the years provide Imperva’s WAF with extensive coverage as more vulnerabilities are protected out of the box to begin with and more have zero-day attacks protection.

For a more thorough understanding of the web application security trends during the last year, we address a number of different vulnerabilities characteristics in the following sections.

Vulnerabilities by Attack Type

Vulnerabilities in web applications can be exploited in different ways, depending on the specific flaw. These different exploitations are often aggregated to attack types groups—like SQL injection, denial of service, etc. To demonstrate, if a web application does not validate user input before querying a database, the flaw can be associated with a SQL injection attack, but probably won’t lead to a directory traversal attack.
In order to analyze the trends from an attack type point of view we looked at the number of new vulnerabilities associated with seven common attacks.

It is interesting to observe that DoS attacks are becoming more common while the rate of XSS attacks has declined. Additionally, buffer overflow vulnerabilities have mildly increased over the last two years.

Vulnerabilities by CMS

Content management system (CMS) are applications used in order to handle digital content (mostly web pages). CMSs are vulnerable to security breaches for a number of reasons. First, they are very popular, so finding and exploiting vulnerabilities in them is profitable. Additionally, some of the major CMSs (including WordPress) are open source, which makes the process of finding security breaches easier. Furthermore, many CMSs support plugins, add-ons, and extensions in addition to their core version. Major CMSs have many plugins, sometimes even tens of thousands. The inflation of plugins and the ease they can be created and added to web applications pose great security risk.

Vulnerabilities by Programming Language

We can see that more vulnerabilities were found in PHP, Python, Ruby, and Perl during 2016 in comparison to 2015, while fewer vulnerabilities were found in Java and .Net framework. Additionally, we can see that the number of vulnerabilities found in any programming language is not proportionate to its market share.

The release of a new PHP version in December 2015 might explain the growth in the amount of discovered vulnerabilities related to PHP. Additionally, PHP is an open source programming language while Java and .NET are distributed by large organizations. It is easier to find and exploit vulnerabilities in an open source project. Therefore, from a security point of view, changes such as new versions and other major code commits have a greater influence over PHP, in comparison to the other major languages.

Conclusion

We witnessed how external events can affect the web application security world and stand out in the type and amount of the vulnerabilities published. In addition, Imperva’s capability to track newly published vulnerabilities, analyze them, and quickly publish virtual patches continues to be a key factor in helping keep Imperva WAF customers protected from vulnerabilities and potential attacks.