Academic Research: Web Application Attacks
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.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
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.
Source link
lol
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…