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

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)

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
> <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?
>
> Bertil
>
>