Who left open the cookie jar? A comprehensive evaluation of third-party cookie policies from the Franken et al., USENIX Security 2018
This paper won a ‘Distinguished paper’ award at USENIX Security 2018, as well as the 2018 Internet Defense Prize. It’s an evaluation of the defense mechanisms built into browsers (and via extensions / add-ons) that seek to protect against user tracking and cross-site attacks. Testing across 7 browsers and 46 browser extensions, the authors find that for virtually every browser and extension combination there is a way to bypass the intended security policies.
When you visit a site A, it can set a cookie to be included in all future requests to that site. This paper is concerned with third-party requests. This is where you visit site B, but some resource on site B triggers a request to be made to site A (for example, an
img tag with a
There are other cross-site attacks too, such as cross-site script scripting (XSS) and cross-site timing attacks.
The same-site cookie mechanism aims to protect against cross-site attacks. Same-site cookies have a
SameSite attribute set by the website that sets the cookie. When set to
lax the cookie can be included only in top-level (the URL in the address bar changes) requests to third-party sites, and when set to
strict the cookie may never be include in cross-site requests. Browser support for same-site cookies in the major browsers is now pretty good.
Ways to generate cross-site requests
In order to exhaustively test all the possible cross-site request mechanisms, the first job is to list them all. The authors found seven different mechanism categories, encompassing hundreds of individual mechanisms between them.
- Perhaps the most obvious class is HTML tags with attributes that can refer to external resources (e.g.
script). There are 196 different ways HTML tags can trigger external requests, many of them documented at HTTPLeaks. All HTML-based request generate GET requests.
- Some response headers (
Content-Security-Policy) may trigger an additional request either as soon as the browser receives the headers or upon certain events. The
report-uridirective indicates a URI to which violations of security policy should be reported (and the forthcoming Reporting API will enable the same). The directive and API are not yet supported by any browser and are ignored in this study.
- Top-level redirects are often not regarded as cross-site requests, but there are scenarios in which they can be abused. For example, a tracker can listen for the
blurevent on the
windowelement which indicates the user switched tabs – at which point it can trigger a redirect in the background.
- The (deprecated but still supported) AppCache API can specify additional resources to be loaded and cached when the user visits a given page.
- ServiceWorkers can fetch resources and use most browser APIs to initiate additional requests (excluding XHR).
Test all the things
The authors put together a test framework that can exercise all of the possible cross-site request mechanisms across different browsers and extensions.
The primary goal of our evaluation was to analyze browsers for which inconsistencies and bypasses would have the largest impact. On the one hand, we included the most popular and widely-used browsers: Chrome, Opera, Firefox, Safari, and Edge. On the other hand, we also incorporated browsers that are specifically targeted towards privacy-aware users…
Browsers were tested using the default settings for their protection mechanisms. In addition, 46 different extensions for the four most popular browsers were tested, selected based on the extension popularity as reported in the respective stores.
The results for the 7 evaluated browsers are summarised in the table below (filled circle indicating cookies were sent with the request).
- Under default configuration, all the main browsers send cookies along with third-party requests. Safari is the exception, and only does so for redirects.
Because PDFs can be included in iframes, and thus made invisible to the end user, and because it can be used to send authenticated POST requests, this bypass technique could be used to track users or perform cross-site attacks without raising the attention of the victim.
31 ad-blocking extensions were evaluated, and bypasses found for all of them:
15 tracking protection extensions were also evaluated, and bypasses found for all of them as well!
A common mistake with extension developers is to register to filter http and https protocol requests, but forget about ws:// and wss:// protocols.
In summary, we found that for every built-in browser protection as well as for every anti-tracking and ad blocking browser extension, there exists at least one technique that can bypass the imposed policies… Based on these results, we argue that our proposed framework is a much-need tool to detect bypasses and evaluate solutions to the exposed leaks.
Testing the same-site cookie mechanism, incorrect behaviours were found with Chrome, Opera, and Edge.
Future work includes evaluating mobile browsers, and extending the test coverage to other policy implementations such as the Local Storage API and Content Security Policy.