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.
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
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.9, 10Templates 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
Our research found 3 CVE vulnerability entries over the past 3 years relating to custom HTML Elements.
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.
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
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.