- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 9 Jan 2014 12:24:32 +0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Ilya Grigorik <igrigorik@google.com>, Joel Weinberger <jww@chromium.org>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>, Brad Hill <bhill@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Tab Atkins <tabatkins@google.com>, William Chan <willchan@google.com>
On 9 Jan 2014, at 8:10 am, Michal Zalewski <lcamtuf@coredump.cx> wrote: > Also, to circle back to the fingerprinting angle: the logged-in state > aside, let's say that there's a HTML page or a JSON response that is > mostly static, except for a first name, e-mail address, or a phone > number somewhere in the body. Further, for the sake of simplicity, > let's say that it's cacheable on the client. > > I could precompute hashes for the static content + every common first > name, every phone number in a particular area code, or any of the > e-mail addresses I care about; and then rapidly attempt to load that > subresource with varying integrity=. By monitoring violations, I could > quickly determine that my victim's name on Facebook is Bob, or that > his number is 650-555-5555, right? > > I don't think this is easily attainable without subresource integrity… Seems like this could be mitigated by only allowing the integrity-enabled cache to consider responses that are storable by a shared cache… you'd need a proviso that any response loaded over HTTPS needs an explicit CC: public. <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#response.cacheability> Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 9 January 2014 04:25:10 UTC