Top Risks

Academic Research: Web Application Attacks

Personally identifiable information and user credentials are the primary nuggets attackers are after when they exploit known vulnerabilities in web applications.
October 10, 2017
10 min. read

This research was conducted on behalf of and exclusively for F5 Labs by graduate students at the University of Washington Tacoma as part of their capstone research project for the Master in Cybersecurity and Leadership program.

Numerous studies have concluded that known vulnerabilities within web applications are the preferred method for hackers to attack online businesses. Business applications are the tools that allow specific business processes and functions to occur and, as such, they are arguably the most important aspect of the business.

As part of a larger study sponsored by F5 Labs on network applications, we conducted cybersecurity research focused on understanding the risks inherent with web applications and their components. The goal of this research is to identify trends in web application security as new technologies and frameworks are established in the industry.

We identified compromised data from reputable sources, based on the industry and type of data targeted between 2014 and 2017. We categorized the data based on the Open Web Application Security Project (OWASP) Top 10 web application threats and examined recent threats to web components.

Research on Web Application Vulnerabilities

We first identified data breaches from reputable sources between 2014 and 2017. We then used recognized standards to categorize and classify data breaches by industry, data type, and web application security threats. We further refined the quality of our analysis by cross-referencing attacks with common vulnerabilities and exposure resources. Three primary data sources were used to identify data breaches by industry and data type:

  • The Privacy Rights Clearinghouse Data Breach Report used to identify the most targeted attack type between 2014 Q1 and 2017 Q2.1
  • The 2017 Data Breach Investigations Report (DBIR) 10th Edition (Verizon), to define industry categories.2
  • The Open Web Application Security Project (OWASP) to broadly classify and categorize the web application attack types.3
  • The Common Vulnerabilities and Exposures website sponsored by the MITRE corporation was leveraged to further isolate the targeted web applications components.4

Analysis of Web Application Breaches

We examined the biggest breaches executed via web applications. Our analysis of web application breaches across industries showed “personally identifiable information” (PII) at 38.78% of the total number of breaches, is the most prominent kind of data, followed closely by “User Credentials” at 32.65%, as shown in the graph below:

Our data for the types of attacks we researched shows that SQL injection is by far the most widely used attack method by hackers since 2014, primarily due to the high reward it often yields with a minimal amount of effort and risk on the attacker’s part.

Another threat that is being exploited commonly appears to be by attacking web application components with known vulnerabilities.

In contrast, our research revealed that cross-site scripting (XSS) actually had a much lower prevalence; rated tenth, to be exact. In addition, our data was a survey of breaches conducted via Internet research. OWASP’s ratings are based on their own rating requirements, which take different data into account.5

Industry Data

We used the industry definitions from Verizon’s DBIR, overlaid the with the OWASP Top Ten Most Critical Web Application Security Risks. From this, we could identify the industries impacted and successful breaches.

From these 49 breaches, it is apparent that the “Information” industry is the most vulnerable by more than double of any other industry. By nature, the “Information” industry has massive amounts of data available to be harvested for resale and other malicious use, as opposed to the relatively small amount of data or high-dollar information that can be easily collected from attacking the “Manufacturing” or “Educational Services” industries.

Web Components Attack Analysis

A traditional framework for software development is the Model View Controller (MVC). It provides a framework for developers to create classes that are reusable without modifications.6 The design consists of a model, which is the data, an interface to view the data, and a controller to perform operations. By inserting the controller class between the model and the view, it reduces dependencies and allows the model and the view to be easily repurposed.

There are many variants of the MVC framework based on different programming languages. These include both server-side (PHP, Java, C#, Ruby) and client-side (JavaScript, CSS) frameworks. Use of these frameworks creates less complex, reusable code and reduces the application’s attack surface.

Many modern web applications use client-side code created using JavaScript and User Interface (UI) toolkits. These toolkits have essentially changed the role of web designers and how they interact with the dedicated client-side JavaScript developers. Web designers have taken on the role of creating UIs, to establish connections with external sources to pass data.7

Web Components

Web Components are an effort to standardize and simplify the complexity involved in web application development. This project, primarily led by Google with their tool Polymer, consist of a collection of HTML5 and CSS standards and technologies to encapsulate widgets and UI elements as “components.”

The design of these components began in large part by the World Wide Web Consortium (W3C) in 2011, which is, per its home page, “an international community that develops open standards to ensure the long-term growth of the web.”8

Each web component provides a different attack surface, regardless of framework or JavaScript library used; many vulnerabilities have already been found via bug bounties or pwn2own, and subsequently patched. While our research did not show many actual breaches executed using web components, there have been several proof-of-concepts and capture-the-flag (CTF) efforts by Google and others to prove potential attack vectors.

HTML Templates Attacks

The HTML Template web component contains markup (code) and/or scripts to be inserted into the Document Object Model (DOM). Templates can be instantiated at the developer’s discretion; an inert template is created, but not put into play until stamped out. This provides a safer execution of data binding (establishing connection between the application UI and the business logic) so that any change in the data is reflected in the elements bound to the data.910Templates can be used to create packages of styles applicable to elements with CSS. Packages are known as Decorators to change font, size, color, etc.

Our research found 76 CVE vulnerability entries over the past 3 years relating to HTML Templates.

HTML Custom Elements

These web components are add-ons for existing HTML elements (that is, connecting button element to JavaScript). These elements are created on a case-by-case basis by web developers. As such, they cannot be “hacked” per se, rather, they are created to execute hacks. At its most benign, these attacks can cause the application or browser to crash. At its worst, it can allow an attacker to execute code on someone’s computer.

Our research found 3 CVE vulnerability entries over the past 3 years relating to custom HTML Elements.

Shadow DOM

The Shadow DOM web component encapsulates and isolates Web Component DOM by segregating a web application page’s master DOM and allowing access to the attributes of HTML elements that would otherwise be inaccessible. The greatest overarching concern that exists with the Shadow DOM web component involves internal code “leaking” out to corrupt the master DOM.

Our research found 4 CVE vulnerability entries over the past 3 years relating to Shadow DOM.

HTML Imports

The HTML Imports web component “imports” another HTML page into the current page, which can be exploited for cross-site scripting (XSS) attacks.  It allows “crowdsourcing” of HTML collections of new API primitives for browsers to use. It has some security mechanisms in place by providing wholesale inclusion of a page. It also takes the place of inline frames (iframes) and can prevent clickjacking (tricking user into clicking hyperlinks beneath legit clickable content11) without the need for frame busting (validation process to block rendering of a window by default until it is confirmed to be the main one12).

Our research found 14 CVE vulnerability entries over the past 3 years relating to HTML Imports.

Review of Web Components

Due to the long bureaucratic process involved in approving web components,13 some of the more prolific and important companies on the Web today began to create their interpretation on web components, developing them into ready-to-use JavaScript libraries. Regardless of which framework the developer uses, Web Components function best in both Google Chrome (Android) and Opera. Mozilla’s Firefox and Apple’s Safari currently (as of 2017) support HTML Templates and are developing Shadow DOM and Custom Elements. Microsoft’s various versions of Internet Explorer (including Edge) do not currently support Web Components in any fashion, although use of HTML Imports, Shadow DOM, and Custom Elements in Edge is under consideration.14

In a deeper analysis of web components, the total number of vulnerabilities were found to be highest in HTML templates. Based on this, and the fact that our only substantiated breach was conducted against it, our team would posit that HTML templates are most at risk. That said, there are multiple recent vulnerabilities with each web application component. So long as web components are billed by W3C as the future of web application development, they will likely continue to be targeted for SQL injection and XSS efforts.

One of our members found it particularly vexing not to be able to find definitive “smoking guns” revealing actual breaches conducted by or against particular web components. Perhaps an effort to refine the search terms used, and a deeper knowledge of web application development, and the intrinsic vernacular therein could provide more fruitful results.

This ties in with the “smoking gun” aspect. Web Components have been used by several of the major names on the Internet since 2013, yet there does not seem to be any proven breaches conducted against them. This is expected, given that breach investigations tend to take months, if not years. Perhaps, in the future, a more macro/strategic-level effort to uncover the technical background for breaches will reveal something more concrete.

Conclusions and Future

It is worth mentioning as per a notice on OWASP’s website posted on August 2, 2017 the risks associated with “Insufficient Attack Protection” and “Underprotected APIs,” which are undergoing reevaluation. This could mean that there will be 12 reports that may need to be reclassified into the new risk categories when the new documentation is published in late November 2017.

Moving forward, we recommend reevaluation of the data set of the items that were not accepted per Top 10 Most Critical Web Application Security Risks RC1 rejections. This new documentation will be published and available on November 20, 2017.

Also, we would recommend continued threat intelligence efforts by establishing good relations with both web application fuzzers and penetration testers to better understand the topography of web application development. This can be done by reaching out to web application developers in the field for their opinions as professionals in their craft.

Join the Discussion
Authors & Contributors
Andrew Cox (Author)
Information Security Sr. Analyst
Daniel Freese (Author)
Matthew Martin (Author)
Network Intelligence Analyst
Daniel Massie (Author)
Footnotes - Privacy Rights Clearinghouse data breaches unpublished raw data.






What's trending?

Forward and Reverse Shells
Forward and Reverse Shells
09/15/2023 article 5 min. read
Web Shells: Understanding Attackers’ Tools and Techniques
Web Shells: Understanding Attackers’ Tools and Techniques
07/06/2023 article 6 min. read
What Is Zero Trust Architecture (ZTA)?
What Is Zero Trust Architecture (ZTA)?
07/05/2022 article 13 min. read