The idea of progressive enhancement has been around for years and the Web platform is continuously enriched with new features.Nonetheless, it is the advent of service workers (SWs) and web app manifests (WAMs) that marked the era of capable, reliable, and installable progressive web applications (PWAs), following prior Web evolutions from a static medium to a dynamic platform.In this work, we introduce ProwseBox, a comprehensive and efficient cross-browser and cross-platform framework for the dynamic, scalable and distributed measurement and analysis of PWAs, SWs -in the web apps, extensions, and Cloudflare workers -and web extensions.Leveraging the capabilities of the flexible, singlethreaded, and event-driven JavaScript, and unique hacks to enable automated interactions with web push notifications or the file system API, ProwseBox produces detailed and structured datasets that researchers, browser vendors, web developers, and end users can apply modern data analysis techniques to, to uncover the evolution, state and (mal) practices on the usage of Web features, browser extensions and edge workers, or assess compliance with specifications, detect anomalies, bugs, vulnerabilities and data leakage.The framework has been extensively (re)engineered, documented, and thoroughly evaluated throughout the years, building on and adapting to the constant evolution of Web APIs.The collected dataset is well-structured and various analysis pipelines are provided for serializing and importing the data into state-of-the-art analysis frameworks like Apache Spark for processing.The framework has served or is currently serving to collect various large-scale data that support both measurement, security, and privacy studies, the most recent one covering 56,505,674 sites in the wild.In a series of case studies, we demonstrate a subset of the framework's capabilities, ranging from the capture of cross-site scripting (XSS) vulnerabilities in web apps and browser extensions, or the discovery of user-sensitive information leakage, etc.Ultimately, we hope to promote ProwseBox as the state-of-the-art tool for studying the progressive Web, much like ZDNS or OpenWPM that fosters replicability and major advances in other communities.

With the increasing prevalence of progressive web applications, web workers have found themselves in the spotlight. Indeed, workers have drastically changed the attack surface of the Web. For instance, prior work has demonstrated unique flaws enabled by service workers, e.g., their computation, persistence, and caching capabilities or their ability to process in the background web push messages and synchronization with the backend. Regarding XSS (cross-site scripting), its treatment in web worker contexts by various Web stakeholders is hugely unsatisfactory and insufficient. Content injection attacks are still primarily framed from the perspective of webpages, including the defense mechanisms [53]. In this work, we undertake the first comprehensive security analysis of content injection attacks in all web workers, focusing on XSS. To do so, we start by defining a transparent threat model, considering that workers are dedicated to code execution but lack a DOM, meaning that the ways attackers infect them differ from web pages. Then, we devise a rigorous methodology we applied to a large-scale dataset of 4,757,077 workers collected from 56,945,781 websites in the wild. As a result, through extensive manual vetting, we confirmed different server and client XSS flavors in at least 89,945 workers affecting 31,619 sites. These vulnerabilities can be attributed to 131 unique frameworks/codebases. We reported our findings to the affected vendors. Many of them acknowledged the issue, and at the time of this writing, the problem has been fixed for at least 82.3% of the vulnerable workers. From a defensive side, we engaged in an extensive discussion with proposals. We demonstrated how to extend the Content Security Policy and the importScripts function implementations to allow the expression and support of finer-grained policies like nonces and hashes, which we believe can help thwart most of the workers’ XSS attacks discussed in this work. We submitted our proposal to the W3C Web Application Security Working Group, reinstating a discontinued discussion on extending nonces and hashes to JavaScript APIs and web workers.

Cross-site scripting (XSS) has constantly remained one of the most prevalent attacks on the Web. In this work, we question its current taxonomy, i.e., the client- or server-side reflected (non-persistent) or stored (persistent) matrix. The Web has extensively changed. Consequently, considering XSS with the lenses of this famous matrix has become at least imprecise, at most impossible for many code injection scenarios where (i) a service worker or an edge worker generates HTTP responses and can reflect or persist XSS payloads infecting not only JavaScript in web pages but also Web assembly, web workers and affecting one or many users automatically; (ii) an attacker sends a web push message directly to a browser push service to trigger code execution in a dormant service worker; or (iii) a cross-origin adversary tampers with code stored by a vulnerable website on the user's physical/permanent file system, etc. Our proposal --to get out of the matrix and not enter another rigid one-- expresses the essence of XSS as code infection and affection attack and allows for clearly specifying the different actors and components involved, their environments, contexts, and storages, as well as their recurrence and persistence seen as a continuum rather than a binary marker. From a defensive perspective, we showcase the challenges and limitations of current mechanisms for mitigating XSS, which targets the entire attack surface of modern websites. Finally, we demonstrate an abuse of the Service-Worker-Allowed header to control entire domains with malicious service workers.

Browser extensions are popular to enhance users' browsing experience. By design, they have access to security- and privacy-critical APIs to perform tasks that web applications cannot traditionally do. Even though web pages and extensions are isolated, they can communicate through messages. Specifically, a vulnerable extension can receive messages from another extension or web page, under the control of an attacker. Thus, these communication channels are a way for a malicious actor to elevate their privileges to the capabilities of an extension, which can lead to, e.g., universal cross-site scripting or sensitive user data exfiltration. To automatically detect such security and privacy threats in benign-but-buggy extensions, we propose our static analyzer DoubleX. DoubleX defines an Extension Dependence Graph (EDG), which abstracts extension code with control and data flows, pointer analysis, and models the message interactions within and outside of an extension. This way, we can leverage this graph to track and detect suspicious data flows between external actors and sensitive APIs in browser extensions. We evaluated DoubleX on 154,484 Chrome extensions, where it flags 278 extensions as having a suspicious data flow. Overall, we could verify that 89% of these flows can be influenced by external actors (i.e., an attacker). Based on our threat model, we subsequently demonstrate exploitability for 184 extensions. Finally, we evaluated DoubleX on a labeled vulnerable extension set, where it accurately detects almost 93% of known flaws.

Browser extensions are third party programs, tightly integrated to browsers, where they execute with elevated privileges in order to provide users with additional functionalities. Unlike web applications, extensions are not subject to the Same Origin Policy (SOP) and therefore can read and write user data on any web application. They also have access to sensitive user information including browsing history, bookmarks, credentials (cookies) and list of installed extensions. They have access to a permanent storage in which they can store data as long as they are installed in the user's browser. They can trigger the download of arbitrary files and save them on the user's device. For security reasons, browser extensions and web applications are executed in separate contexts. Nonetheless, in all major browsers, extensions and web applications can interact by exchanging messages. Through these communication channels, a web application can exploit extension privileged capabilities and thereby access and exfiltrate sensitive user information. In this work, we analyzed the communication interfaces exposed to web applications by Chrome, Firefox and Opera browser extensions. As a result, we identified many extensions that web applications can exploit to access privileged capabilities. Through extensions' APIs, web applications can bypass SOP and access user data on any other web application, access user credentials (cookies), browsing history, bookmarks, list of installed extensions, extensions storage, and download and save arbitrary files in the user's device. Our results demonstrate that the communications between browser extensions and web applications pose serious security and privacy threats to browsers, web applications and more importantly to users. We discuss countermeasures and proposals, and believe that our study and in particular the tool we used to detect and exploit these threats, can be used as part of extensions review process by browser vendors to help them identify and fix the aforementioned problems in extensions.

Modern browsers implement different security policies such as the Content Security Policy (CSP), a mechanism designed to mitigate popular web vulnerabilities, and the Same Origin Policy (SOP), a mechanism that governs interactions between resources of web pages.