The DOM tree is a central part of modern web development, enabling JavaScript to interact with page content and structure. Only a few prior studies have studied its trustworthiness, despite its widespread use in guiding program logic and security decisions. Most notably, script gadgets have shown how this trust can be exploited by triggering the execution of benign JavaScript fragments with seemingly harmless markup injections. In this paper, we show that script gadgets are only the tip of the iceberg. Seemingly-benign markup injections can trigger the execution of fragments - that we call DOM gadgets - that, unlike script gadgets, do not necessarily result in a cross-site scripting vulnerability. Instead, they can result in a broader set of attacks, such as browser request hijacking attacks, cross-site request forgery attacks, and user interface manipulations.

Request forgery attacks are among the oldest threats to Web applications, traditionally caused by server-side confused deputy vulnerabilities. However, recent advancements in client-side technologies have introduced more subtle variants of request forgery, where attackers exploit input validation flaws in client-side programs to hijack outgoing requests. We have little-to-no information about these client-side variants, their prevalence, impact, and countermeasures, and in this paper we undertake one of the first evaluations of the state of client-side request hijacking on the Web platform.Starting with a comprehensive review of browser API capabilities and Web specifications, we systematize request hijacking vulnerabilities and the resulting attacks, identifying 10 distinct vulnerability variants, including seven new ones. Then, we use our systematization to design and implement Sheriff, a static-dynamic tool that detects vulnerable data flows from attacker-controllable inputs to request-sending instructions. We instantiate Sheriff on the top of the Tranco top 10K sites, performing, to our knowledge, the first investigation into the prevalence of request hijacking flaws in the wild. Our study uncovers that request hijacking vulnerabilities are ubiquitous, affecting 9.6% of the top 10K sites. We demonstrate the impact of these vulnerabilities by constructing 67 proof-of-concept exploits across 49 sites, making it possible to mount arbitrary code execution, information leakage, open redirections and CSRF also against popular websites like Microsoft Azure, Starz, Reddit, and Indeed. Finally, we review and evaluate the adoption and efficacy of existing countermeasures against client-side request hijacking attacks, including browser-based solutions like CSP, COOP and COEP, and input validation.

Browser fingerprinting is an effective technique to track web users by building a fingerprint from their browser attributes. It is also stealthy because the tracker uses legitimate JavaScript API calls offered by the browser engine, which can be obfuscated before they are sent to a (third-party) server. Current browser fingerprinting methodologies employ coarse-grained collection and classification techniques, such as binary classification of fingerprinters based on the number of non-obfuscated exfiltrated attributes. As a result, they produce inconsistent findings. Meanwhile, the privacy of millions of web users is at risk daily. We address this gap by presenting FP-tracer, a novel methodology to detect and classify browser fingerprinters based on dynamic taint tracking and joint entropy classification. Our methodology enables detecting first- and third-party fingerprinters even when they use obfuscation by tainting attributes, propagating them, and logging when they are leaked (via 62 sources and 25 sinks). Moreover, it discriminates the invasiveness of fingerprinting activities, even from the same service, by measuring the joint entropy of the collected attributes and clustering them. We implement FP-tracer by extending Foxhound, a privacy-oriented Firefox fork with numeric type tainting, more taint tracking sources and sinks, support for multiple sources, and better logging capabilities. We embed our implementation in our automated crawling infrastructure, which is capable of testing websites in parallel using programmable and reproducible logic. We will open-source our implementation. We evaluate FP-tracer by performing a large-scale crawl over the Tranco Top 100K, and detect, amongst others, audio, canvas, and storage fingerprinting on the web. Among others, we find high fingerprinting activities in 8% of domains, with more moderate activity reaching 75%. Notably, fingerprinting is almost five times more likely to be performed by third-party scripts for high activity levels. In addition, we measure that the most severe category of fingerprinting obfuscates 46% of transmitted attributes, and 38% of fingerprinters involve two or more domains. Finally, we find that existing consent banners do not provide an effective defense against browser fingerprinting

Recent advances in data protection regulations brings privacy benefits for website users, but also comes at a cost for operators. Retrofitting the privacy requirements of laws such as the General Data Protection Regulation (GDPR) onto legacy software requires significant auditing and development effort. In this work we demonstrate that this effort can be minimized by viewing data protection requirements through the lens of information flow tracking. Instead of manual inspections of applications, we propose a lightweight enforcement engine which can reliably prevent unlawful data processing even in the presence of bugs or misconfigured software. Taking GDPR regulations as a starting point, we define twelve software requirements which, if implemented properly, ensure adequate handling of personal data. We go on to show how these requirements can be fulfilled by proposing a metadata structure and enforcement policies for dynamic information flow tracking frameworks. To put this idea into practice, we present Fontus, a Java Virtual Machine (JVM) information flow tracking framework, which can transparently label personal data in existing Java applications in order to aid compliance with data protection regulations. Finally, we demonstrate the applicability of our approach by enforcing data protection polices across 7 large, open source web applications, with no changes required to the applications themselves.

The General Data Protection Regulation (GDPR) and related regulations have had a profound impact on most aspects related to privacy on the Internet. By requiring the user’s consent for e.g., tracking, an affirmative action has to take place before such data collection is lawful, leading to spread of so-called cookie banners across the Web. While the privacy impact and how well companies adhere to those regulations have been studied in detail, an open question is what effect these banners have on the security of netizens.

Despite the considerable amounts of resources invested into securing the Web, Cross-Site Scripting (XSS) is still widespread. This is especially true for Client-Side XSS as, unlike server-side application frameworks, Web browsers do not ship with standard protection routines, so-called sanitizers. Web developers, therefore, have to either resort to third-party libraries or write their own sanitizers to stop XSS in its tracks. Such custom sanitizer routines – dubbed hand sanitizers in the following – are notoriously difficult to implement securely. In this paper, we present a technique to automatically detect, extract, analyze, and validate JavaScript sanitizer functions using a combination of taint tracking and symbolic string analysis. While existing work evaluates server-side sanitizers using a small number of applications, we present the first large-scale study of client-side JavaScript sanitizers. Of the most popular 20,000 websites, our method detects 705 unique sanitizers across 1,415 domains, of which 12.5% are insecure. Of the vulnerable sanitizers, we were able to automatically generate circumventing exploits for 51.3% of them, highlighting the dangers of manual sanitization attempts. Interestingly, vulnerable sanitizers are present across the entire range of website rankings considered, and we find that most sanitizers are not generic enough to thwart XSS if used in just a slightly different context. Finally, we explore the origins of vulnerable sanitizers to motivate adopting a standardized sanitization API available directly in the browser.