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

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

From: Eric Lawrence <Eric.Lawrence@microsoft.com>
Date: Tue, 25 Sep 2018 14:39:43 +0000
To: Devdatta Akhawe <dev.akhawe@gmail.com>, Bertil Chapuis <bchapuis@gmail.com>
CC: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Kévin Huguenin <kevin.huguenin@unil.ch>, Igor Bilogrevic <ibilogrevic@google.com>, Mike West <mkwst@google.com>
Message-ID: <BN6PR21MB0787316165A8CD0D2B9A1991F7160@BN6PR21MB0787.namprd21.prod.outlook.com>
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<mailto:bchapuis@gmail.com>> wrote:
On Thu, 20 Sep 2018 at 15:46, Frederik Braun <fbraun@mozilla.com<mailto: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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebappsec-subresource-integrity%2Fissues%2F68&data=02%7C01%7CEric.Lawrence%40microsoft.com%7C22d9bc1d08184e61328508d62020da79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636731722809325486&sdata=5FqrwaHe5XxpUzb20nD17jsHb9qUhTnGmwoGlmy3FtU%3D&reserved=0>
> >> 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?

Received on Tuesday, 25 September 2018 14:40:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 September 2018 14:40:09 UTC