HTTPS://ARTURJANC.COM:443/

Application security engineers frequently grapple with the fact that web origins are only incidentally separated from one another; web security rules permit a surprising number of interactions which can be used to modify or infer the state of unrelated applications. The resulting attack surface is -- sadly -- one of the defining characteristics of the web security model, enabling multiple classes of hard-to-fix information leaks.

In recent years, the lack of true web isolation has led to problems on three main fronts. First, vulnerabilities exploitable via malicious cross-site interactions, such as CSRF and XSSI have continued to plague major applications. Second, XS-Leaks research has identified practical new attacks that exploit both legacy and new web platform behaviors, and resulted in new avenues to leak cross-origin data. Finally, transient execution vulnerabilities such as Spectre and Meltdown broke the illusion that the web is immune to CPU-level bugs, demonstrating tractable cross-site attacks based on leaking data in the address space of the attacking origin's web renderer process.

In response, web browsers have proposed and implemented major security mechanisms that give application developers the ability to lock down their applications from unwanted cross-origin interactions.

This talk covers the details of these features, focusing on Fetch Metadata Request Headers and Cross-Origin Opener Policy as means to isolate an application from the rest of the web. We share information from production rollouts of these features at Google to review deployment strategies and potential pitfalls. We also brainstorm the types of attacks that may be possible even in light of these restrictions, and discuss application patterns that developers will need to change to more comprehensively defend their sites.

This talk grappled with a fairly important question: what lies at the heart of the widespread insecurity of the web ecosystem?

The answer — at least in part — can be traced back to design choices made decades ago, when the goals and trade-offs for decisions affecting the web were fundamentally different than they are today. That is, the stunning success of the web as an application platform led to a situation where the security properties of the web haven't kept pace with the popularity and sensitivity of its applications.

Specifically, the talk argues for addressing the lack of safety of the web in three ways: designing new security mechanisms, deprecating unsafe legacy behaviors, and emphasizing security and privacy during the design of new web APIs.

Appropriately for a serious venue such as USENIX, the slides also feature dancing hamsters.

Recognizing the importance of adding security mechanisms to the web platform, browser vendors have recently shipped a bevy of powerful features that allow developers to protect their applications. This talk goes into detail about two major types of web security problems: injections and lack of isolation, and discusses four modern security mechanisms that protect against them: CSP3, Trusted Types, Fetch Metadata Request Headers, and Cross-Origin Opener Policy.

Here is the talk in one slide: If you prefer your information in video form, you can watch this talk on YouTube.

This talk gives an overview of the classes of vulnerabilities affecting the Google ecosystem, focusing on web application bugs — the majority of the high-risk issues reported under the Google VRP.

Going somewhat beyond reviewing bug trends, the talk categorizes web security issues into three main classes: lack of transport safety, injections, and cross-site leaks. It outlines how the specifications owned by the W3C WebAppSec working group map to the defensive mechanisms application developers need to secure their applications.

It is a precursor to the USENIX Security talk.

This short talk described the results of the adoption of strict CSP at Google, including a review of browser features that would help application developers during their CSP deployments.

The second half of the talk discusses results from a study of the feasibility of adopting suborigins based on data from an experimental Chrome extension to test suborigins compatibility.

Modern JavaScript frameworks make web development much easier, but they also carry a risk of introducing new classes of vulnerabilities. In particular, given the ease with which XSS bugs can creep into an otherwise well-behaved codebase, new client-side APIs carry the risk of introducing new inection vectors.

This talk provices an overview of the types of vulnerabilities common in AngularJS applications, from client-side template injections to XSS in native AngularJS APIs such as $http.jsonp, $http.get, $interpolate, $compile, and $parse.

What's the worst that can happen when your application suffers from XSS? We're all used to demonstrating injections with alert(document.domain), but it's worthwhile to think about the malicious potential of a serious XSS bug in a sensitive applica­tion, especially if exploited by a motivated and capable attacker.

This talk goes into detail about the avenues to achieve persistence after script execution, pointing out a fair number of similarities to system-level compromises.

This W2SP talk discussed the dangers of attacks on browsing history using the CSS :visited pseudoclass. In a nutshell, it was bad (more details are in the papers linked in the research section) and browser vendors took steps to fix the problem.

Conducted in collaboration with Lukasz Olejnik, this bit of practical research demonstrated the potential of the AmbientLightSensor API to leak sensitive data to websites.

In short, readings from the sensor may allow websites to infer the color of the user's screen; in the simplest variant, determine whether it's black or white depending on the amount of reflected light reaching the sensor. Interestingly, this becomes a side-channel information leak in cases where the website is prohibited from directly learning the color of the screen (for example when displaying cross-origin frames or images).



All the cool details are described in Lukasz's blog post.

One of the best ways to understand the common patterns of web vulnerabilities — XSS, CSRF, clickjacking and XS-leaks — is to try your hand at exploiting them in a real, vulnerable application.

The XSS Game, meant for regular web developers rather than seasoned security professionals, is a simple introduction to the topic of cross-site scripting, guiding the player through six levels of increasing difficulty. It is an external version of a security exercise used for many years as part of the Google SWE onboarding process.

The game has been played by hundreds of thousands of developers and is a common part of a considerable number of web security courses.



Note: Since this project launched, several high-quality web security resources have sprung up, offering a more comprehensive introduction to web security. If you're looking for a refresher course, check out the Web Security Academy.

Since the very beginnings of the web, the CSS :visited pseudoclass has been known to reveal users' web browsing histories by allowing sites to style visited links differently from unvisited ones and then read the color with which the links are displayed.

whattheinternetknowsaboutyou.com (WTIKAY) was a site demonstrating the privacy impact of this information leak, showing how any web page could check for millions of visited URLs in a matter of minutes. WTIKAY used some fairly nifty tricks such as highly optimized history detection and integration with search engines to perform a deep checks of URLs on sites the user had visited.



Soon after this research was published, browsers took steps to mitigate this issue. In 2020, research done by Sarah Bird et al. from Mozilla and published at SOUPS, replicated the results and confirmed its major conclusions.

Lingro is my would-be startup project, launched out of college with my friend Paul Kastner. It's a somewhat flexible online dictionary that helps you read in a foreign language and easily look up words you don't know; it saves each word in its original context to make it easier for you to learn vocabulery.

The dictionaries used in Lingro are all based on freely-licensed sources and translations can be contributed by anyone. Since launch, Lingro has translated over 4 million words and is still actively used by a few thousand users each month.

Abstract

In its transition from the original concept of a mesh of hypertext documents into the world's most successful application ecosystem, the open web platform has steadily, iteratively, accumulated a large number of unsafe features and behaviors. These features lead to vulnerabilities in web applications, enable attacks on web users, and often add significant complexity to developers' mental models of the web and to user-agent implementations.

In this paper, we start from a scattered list of concrete grievances about the web platform based on informal discussions among browser- and web security engineers. After reviewing the details of these issues, we work towards a model of the root causes of the problems, categorizing them based on the type of risk they introduce to the platform. We then identify possible solutions for each class of issues, dividing them by the most effective approach to address it.

In the end, we arrive at a general blueprint for backing out of these dead ends. We propose a three-pronged approach which includes changing web browser defaults, creating a slew of features for web authors to opt out of dangerous behaviors, and adding new security primitives. We then show how this approach can be practically applied to address each of the individual problems, providing a conceptual framework for solving unsafe legacy web platform behaviors

Abstract

Intelligent Tracking Prevention (ITP) is a privacy mechanism implemented by Apple's Safari browser, released in October 2017. ITP aims to reduce the cross-site tracking of web users by limiting the capabilities of cookies and other website data.

As part of a routine security review, the Information Security Engineering team at Google has identified multiple security and privacy issues in Safari's ITP design. These issues have a number of unexpected consequences, including the disclosure of the user's web browsing habits, allowing persistent cross-site tracking, and enabling cross-site information leaks (including cross-site search).

This report is a modestly expanded version of our original vulnerability submission to Apple (WebKit bug #201319), providing additional context and edited for clarity. A number of the issues discussed here have been addressed in Safari 13.0.4 and iOS 13.3, released in December 2019.

Abstract

Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern web applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.

We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies — the most comprehensive study to date. We introduce the security-relevant aspects of the CSP specification and provide an in-depth analysis of its threat model, focusing on XSS protections. We identify three common classes of CSP bypasses and explain how they subvert the security of a policy.

We then turn to a quantitative analysis of policies deployed on the Internet in order to understand their security benefits. We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS.

Finally, we propose the 'strict-dynamic' keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on domain whitelists. We discuss our experience deploying such a nonce-based policy in a complex application and provide guidance to web authors for improving their policies.

Abstract

We present the results of the first large-scale study of the unique­ness of Web browsing histories, gathered from a total of 368,284 Internet users who visited a history detection demon­stration website.

Our results show that for a majority of users (69%), the browsing history is unique and that users for whom we could detect at least 4 visited websites were uniquely identified by their histories in 97% of cases. We observe a significant rate of stability in browser history fingerprints: for repeat visitors, 38% of fingerprints are identical over time, and differing ones were correlated with original history contents, indicating static browsing preferences (for history subvectors of size 50). We report a striking result that it is enough to test for a small number of pages in order to both enumerate users' interests and perform an efficient and unique behavioral fingerprint; we show that testing 50 web pages is enough to fingerprint 42% of users in our database, increasing to 70% with 500 web pages.

Finally, we show that indirect history data, such as information about categories of visited websites can also be effective in fingerprinting users, and that similar fingerprinting can be performed by common script providers such as Google or Facebook.

Abstract

Browser history detection through the Cascading Style Sheets visited pseudoclass has long been known to the academic security community and browser vendors, but has been largely dismissed as an issue of marginal impact.

In this paper we present several crucial real-world considerations of CSS-based history detection to assess the feasibility of conduc­ting such attacks in the wild. We analyze Web browser behavior and detectability of content returned via various protocols and HTTP response codes. We develop an algorithm for efficient examination of large link sets and evaluate its performance in modern browsers. Compared to existing methods our approach is up to 6 times faster, and is able to detect as many as 30,000 links per second in recent browsers on modern consumer-grade hardware.

We present a web-based system capable of effectively detecting clients' browsing histories and categorizing detected information. We analyze and discuss real-world results obtained from 271,576 Internet users. Our results indicate that at least 76% of Internet users are vulnerable to history detection; for a test of most popular Internet websites we were able to detect, on average, 62 visited locations. We also demonstrate the potential for detecting private data such as zipcodes or search queries typed into online forms. Our results confirm the feasibility of conducting attacks on user privacy using CSS-based history detection and demonstrate that such attacks are realizable with minimal resources.

This Google Security Blog post covers how the ISE team at Google deploys web platform security mechanisms to protect our sensitive applications from two major classes of security bugs: injections (XSS) and issues that undermine isolation between applications (XS-leaks).

Specifically, it outlines our work on Trusted Types, nonce-based Content Security Policy, Fetch Metadata Request Headers and the Cross-Origin Opener Policy.

We live in a world with transient execution vulnerabilities, where a browsing process running attacker's JavaScript can load cross-site resources, or potentially share memory with the process belonging to another origin. This poses significant problems for browser developers and application owners because it undermines fundamental security guarantees we've come to expect from the web.

This article goes into details about two mechanisms: Cross-Origin Opener Policy and Cross-Origin Embedder Policy, that – when used together – provide sufficient isolation that allows a browser to give a document access to powerful low-level APIs.

The Web Almanac project is an ambitious attempt to capture the state of the web across various axes: what are web pages composed of an what this means for user experience, performance, accessibility, and, yes, security.

The Security chapter, written primarily by Scott Helme with a few contributions from yours truly, reviews the web-wide use of defensive mechanisms to protect applications from common web vulnerabilities. It's a fairly comprehensive analysis with a possibly thought-provoking list of features useful to developers of sensitive webapps.

This survey paper outlines, at a high level, the classes of web attacks which are exempt of the confines of the same-origin policy, leading to endemic vulnerabilities such as CSRF, XSSI, clickjacking and cross-site search.

It evaluates proposals for several new web isolation mechanisms – CORB, CORP, Fetch Metadata, SameSite cookies and COOP – from the point of view of the protections they offer against these bugs.

Perhaps most importantly, it makes a case for a principled approach to these types of problems by designing more comprehensive security features that address the bulk of the known sources of cross-origin leakiness.

The concept of an origin is baked into the web platform like almost no other feature, defining the trust principal underpins pretty much all web security. This makes any changes to this concept particularly tricky because of the ripple effects they send through the very fabric of the web.

But what if we could make it more extensible? Allowing developers to define more granular origins could provide strong protections against common vulnerabilities such as XSS. This paper makes a case that such work would be beneficial for the web in the long run.

In a fairly exciting bit of work with the incomparable lcamtuf we took a broad look at fingerprinting vectors available to websites.

Since the paper was written, fingerprinting and device identifica­tion have become even more of a hot topic, but the paper has aged fairly well: many of the vectors outlined in the document continue to pose significant problems for browser vendors' comprehensive anti-fingerprinting efforts.

Legacy Content Security Policy configurations based on URL whitelists have been shown to be ineffective as a countermeasure against XSS. Instead, an approach based on script nonces offers significant adoption and security benefits, and is the preferred method of deploying CSP in large applications at Google.

This documentation explains the nonce-based strict CSP approach in detail.

What is XSS? If you need a refresher with some interactive examples, this page is surely just what you need.