W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: [integrity] content-addressable cache?

From: Mark Goodwin <mgoodwin@mozilla.com>
Date: Wed, 8 Oct 2014 01:43:17 -0700 (PDT)
To: Brad Hill <hillbrad@gmail.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Frederik Braun <fbraun@mozilla.com>, public-webappsec@w3.org
Message-ID: <1713987505.16606505.1412757797894.JavaMail.zimbra@mozilla.com>
> There's another privacy issue lurking in the "determine cross-origin state
> without clobbering", but that's a different attack.

Expanding on this; by selectively serving resources with integrity attributes, malicious web applications could use content-addressable storage (CAS) to track users with "CAS cookies" (e.g. for evercookies).

This relies on the assumption that an attacker could use mismatching src and integrity attributes on an element to determine if CAS contains something matching a given integrity value (since CAS would mean the resource at src doesn't need to be fetched if the cached version exists).

Here's how it would work:
* the attacker chooses an n-bit identifier to assign to a visitor
* a document is served to the visitor containing elements with a specific integrity attribute set for each set bit of the identifier
* the visiting client stores each such resource in CAS
* Some time later (on any origin), a document is served containing all n elements with integrity attributes which could possibly have been set on the first visit, all with mismatched sources.
* The combination of which elements work (and which don't) make up the n-bit identifier - the application can determine, from the successfully loaded resources which of the n-bits of the identifier were set

To mitigate this, user agents would need to ensure that simply setting an integrity attribute does not result in a content-accessible cache entry becoming available. Perhaps entries could be written if a matching resource is observed from a number of different origins, for example. I'm sure others will have thoughts on this.
Received on Wednesday, 8 October 2014 08:43:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:41 UTC