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

Re: [Integrity] Some comments on Cross-Origin leakage and content types

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Thu, 25 Sep 2014 11:43:41 -0700
Message-ID: <CAPfop_1H=GwArE+-jZ7bVjc8yuHL_GiFk2Vb1BxThP1BYXp_Hg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC