WWXSS: Systematic Study, and Large-Scale Measurement of Cross-Site Scripting (XSS) in Web Workers Contexts

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.