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

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

From: Frederik Braun <fbraun@mozilla.com>
Date: Thu, 20 Sep 2018 15:46:14 +0200
To: Bertil Chapuis <bchapuis@gmail.com>, dev.akhawe@gmail.com
Cc: public-webappsec@w3.org, Kévin Huguenin <kevin.huguenin@unil.ch>, Igor Bilogrevic <ibilogrevic@google.com>, Mike West <mkwst@google.com>
Message-ID: <34f5d9c5-e23a-fc83-abbf-514367053f87@mozilla.com>

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
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.
Received on Thursday, 20 September 2018 13:46:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:04 UTC