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

Re: Extending Subresource integrity to more elements (<a>, <img>, etc.)

From: Bertil Chapuis <bchapuis@gmail.com>
Date: Wed, 26 Sep 2018 19:16:01 +0200
Message-ID: <CAPb0btgWXToR4fgFfV-T8U1St5B2XTT0WJ=LZz5gPebdUSY=iA@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Eric.Lawrence@microsoft.com, fbraun@mozilla.com, public-webappsec@w3.org, Kévin Huguenin <kevin.huguenin@unil.ch>, Igor Bilogrevic <ibilogrevic@google.com>, Mike West <mkwst@google.com>
On Tue, 25 Sep 2018 at 18:49, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>
> I haven't dug in heavily but I am imagining:
>
> 1. Allow download attribute on cross origin resources if cross-origin attribute exists
> 2. Allow integrity work as expected when download attribute exists (so just works on same origin and needs cross-origin attr on x-origin resources)

Thanks for your inputs. If I understand correctly it would mean that
the integrity attribute would be used as follows (on a page at
https://www.website.com):

<a href="https://www.website.com/file.exe" integrity="hash" download>

or (if the file has a different origin):

<a href="https://www.another-website.com/file.exe"
crossorigin="anonymous" integrity="hash" download>

Today, the first option brings little as the considered threat arises
mostly in cross-origin contexts (website + CDN) and the second option
is in conflict with the same-origin requirement of the download
attribute.

The fact that the specs of the download and integrity elements are
interdependent complexifies the problem. Just to be sure we are on the
same page, could anyone recall what were the security reasons for
restricting the download attribute to same origins?

> On Tue, 25 Sep 2018 at 07:39, Eric Lawrence <Eric.Lawrence@microsoft.com> wrote:
>>
>> Is the proposal here to respect the Download attribute on a cross-origin resource only when cross-origin is set or integrity is provided and matches?
>>
>>
>>
>> (If not, we reintroduce the same security problems that resulted in the Download attribute being restricted to Same-Origin to begin with.)
>>
>>
>>
>> From: Devdatta Akhawe <dev.akhawe@gmail.com>
>> Sent: Friday, September 21, 2018 7:17 PM
>> To: Bertil Chapuis <bchapuis@gmail.com>
>> Cc: Frederik Braun <fbraun@mozilla.com>; public-webappsec@w3.org; Kévin Huguenin <kevin.huguenin@unil.ch>; Igor Bilogrevic <ibilogrevic@google.com>; Mike West <mkwst@google.com>
>> Subject: Re: Extending Subresource integrity to more elements (<a>, <img>, etc.)
>>
>>
>>
>> Not sure I understand. I think Freddy is saying that it's reasonable to require people to add both the integrity attribute, the download attribute, and the cross origin attribute. Basically, we don't need to implicitly make integrity also mean the cross origin and download attribute.
>>
>>
>>
>> I agree with him. Not tying things together is cleaner and more flexible. I don't think the overhead for developers is that high.
>>
>> On Fri, Sep 21, 2018, 12:26 PM Bertil Chapuis <bchapuis@gmail.com> wrote:
>>
>> On Thu, 20 Sep 2018 at 15:46, Frederik Braun <fbraun@mozilla.com> wrote:
>> > On 19.09.2018 14:55, Bertil Chapuis wrote:
>> > > Hello Dev,
>> > >
>> > >> There is a lot of history here
>> > >> https://github.com/w3c/webappsec-subresource-integrity/issues/68
>> > >> The spec work is a bit tricky too given that you need to define the cross origin tag for anchor etc. But if @annevk is helping, I am confident most spec issues can be resolved.
>> > >
>> > > Thanks for the pointer, we noticed this issue but still had a couple
>> > > of questions regarding the ongoing discussion.
>> > >
>> > > In our understanding, the download attribute currently informs the
>> > > browser to download the resource pointed by a link, even if the
>> > > Content-Disposition header of the HTTP response is not set. As
>> > > suggested by @annevk, as this attribute only works for same-origin
>> > > URLs, an exception for anchor tags that include both the cross-origin
>> > > and the download attributes could be introduced. As these attributes
>> > > are not mandatory, wouldn't it be more appropriate to simply trigger a
>> > > download if the integrity tag is present (regardless of the MIME type,
>> > > Content-Disposition or download attribute)?
>> > >
>> > > Note that from a security perspective, the integrity attribute is less
>> > > needed in the same-origin context.
>> > >
>> > > As hinted by @mikewest, CORS is required to prevent the exposition of
>> > > the content of the resource via hashes. However, if anchor tags
>> > > containing integrity attributes systematically trigger downloads in a
>> > > fire-and-forget fashion, would such exposition of the content occur?
>> >
>> > Implicitly conflating attributes for some elements, but not for others
>> > is too surprising, imho.
>> > I do agree, that the use case for integrity on same-origin is certainly
>> > smaller.
>> > But if the `integrity` attribute secretly implied a cors-anonymous
>> > request, you'd effectively disallow same-origin downloads that require
>> > authentication cookies to work with integrity. And disallowing that
>> > completely is also odd.
>>
>> Fair point, I totally agree that this could be problematic. In this
>> regard, the idea of introducing an exception for the anchor tags (that
>> include both the cross-origin and the download attributes) is much
>> clearer. However, if we don't introduce an exception for the
>> same-origin constraint, I would go so far as to say that checking the
>> integrity is useless, i.e., an attacker gaining access to the origin
>> can change both the resource and its checksum. As the status quo is
>> not ideal neither, do you have another alternative in mind?
>>
>> Bertil
Received on Wednesday, 26 September 2018 17:16:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 26 September 2018 17:16:36 UTC