Dual-key cache/cookie same-origin policy

Edward Pastuszenski

Contents

1. Description
2. How it Works
1. High Level Overview
2. Some Technical Details
3. How to Use It

Description

The same-origin policy project modifies TorButton in order to prevent non-cooperative and semi-cooperative cross-site tracking while using Tor and TorButton.

How It Works

High Level Overview

TorButton protects Tor users from deanonymization by hiding, disabling, or clearing (on Tor toggle) much of the state stored by their browser. However, TorButton does little to manage enabled storage formats, including cookies and cache, during each Tor session. This enables third parties who are semi-cooperative with sites visited by the user to store uniquely identifying files that can be used to track users for the duration of their sessions. These files can assist in or accentuate the effects of certain deanonymizing attacks.

The adversary in the project's core threat model is semi-cooperative with a range of sites, allowed to embed web content in frames on those sites but not explicitly allowed to track visiting users. Such an adversary can store an identifying cache file or cookie on a normal Tor user's computer, and as those file types are partitioned only by content host, that file can be read by the adversary's frames on any semi-cooperating site later visited by that user.

If the adversary also controls a Tor entry node, they can use these files to identify the IPs of all Tor users connecting to semi-cooperating sites through that node. If the adversary has already identified the IP of a user who visits a semi-cooperating site, the files will allow them to track that user's later visits, even if their Tor circuit changes.

The solution to this problem is to partition cache and cookie files by both the content host and the host of the embedding page. This allows embedded content to set state and track users within a single site, unlike conventional third party cookie blocking policies, but it eliminates cross-site tracking by embedded frames.

Some Technical Details

The project's TorButton modifications intercept cache queries and cookie transmission from HTTP request and response headers.

1. Cache

An integer hash of the the domain of the embedding page is added to the cacheKey of each caching HTTP request. Identically named cache files stored by the same frame on different pages will have matching "uri" fields but will disagree in their id fields, and so two separate files will be cached.

2. Cookies

The domain of the embedding page is concatenated to the name of each cookie in a SetCookie response header. Identically named cookies stored by the same frame on different pages will have different local names, and so two separate cookies will be stored. If the embedding domain of a cookie matches that of a HTTP request, the domain will be stripped from the cookie's name (leaving only the name given to it by the server) in the Cookie request header.

Note that the above procedure does not handle cookies set or retrieved using scripting languages. Unfortunately, the Firefox extension API appears unable to intercept these events, so this functionality cannot be built into TorButton.

How to Use It

1. Download this Firefox extension.

2. Install the extension (Firefox 4 required). The majority of the code in the extension is from TorButtion 1.3.3 alpha, which is documented at the Tor Project website.

3. The same-origin policy can be configured in the Cache tab of the Security Settings in the TorButton preferences.

Source code

The extension file linked above can simply be unzipped to access the source code. The major additions to TorButton are in /chrome/content/stanford-safecache.js.