- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Thu, 25 Sep 2014 11:43:41 -0700
- To: Ángel González <angel@16bits.net>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
aah yeah. Any suggestions on how we can fix this issue? On 25 September 2014 11:38, Ángel González <angel@16bits.net> wrote: > Devdatta Akhawe wrote: >> Aah -- so are you saying that >> >> When bank.com uses SRI to fetch same origin resource with integrity >> meta data, it shouldn't happen that tomorrow attacker.com should be >> able to bruteforce the value because it is already in the >> integrity-based cache? I don't think thats the intent of the spec, but >> before I get into that; can you confirm this is your concern? > > I think he means that attacker.com shouldn't be able to discover if he > is a bank.com customer or not. > > That's the >> 4.1 Caching Risks should document the privacy risk (history reading) >> of loading by hash a resource used on a specific site. > I reported last week. > > OTOH if he is going to use timing, I think it is already possible to > check that way if it's in the cache or not. IMHO there's a bigger issue > if it implements the hash-as-cache-keys, as then there is no timing > involved: not customers won't be able to load it. > > > PS: Unless I missed something, the problem you understood is already > mentioned in 6.3 Cross-origin data leakage. > > >
Received on Thursday, 25 September 2014 18:44:31 UTC