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

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 Friday, 21 September 2018 19:27:18 UTC