9

I'm quite enthusiastic about the Sub resource integrity (SRI) features. But, why is it only limited to JS and CSS files? I tried to pin a LESS (CSS variant) file, of which the integrity tag was ignored by Firefox and Chrome.

Additionally, I understand that SRI is mainly designed to protect against unwanted changes of files, hosted on external sources like content delivery networks (CDN's). But since we all love layered security, why not add it on all browser included files (even self-hosted)?

Even if you'd be able to change a JS file, it's likely (but not sure) you'd be able to change the integrity tag as well.

Anders
  • 64,406
  • 24
  • 178
  • 215
Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
  • How did you go about pinning a LESS file? – Arminius Mar 16 '17 at 23:22
  • @Arminius I don't understand your question. – Bob Ortiz Mar 18 '17 at 00:19
  • 2
    Regarding "why not add it on all browser included files (even self-hosted)?": it's perfectly fine to add it on all browser-included files. In fact if you use the [`require-sri-for`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for) CSP directive, you will need SRI for all scripts, styles, or both, regardless of whether they are cross-origin or same-origin. – rink.attendant.6 Feb 22 '18 at 03:51
  • This problem can be solved by using a javascript function, served from the same server that the trusted checksum is served from, to verify the integrity of the download from the untrusted server. See https://www.meixler-tech.com/aivwd/ for more info. – mti2935 Feb 24 '20 at 16:32

1 Answers1

7

Why is it limited to JS and CSS resources?

But, why is it only limited to JS and CSS files?

The W3C SRI specification states:

The scheme specified here also applies to link and future versions of this specification are likely to expand this coverage.

It also states:

A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

It seems that this is just the first version of the specification. The github repository also includes a milestone referencing issues the second version of the specification will address. For example, there is a github issue regarding adding the ability to add the integrity for downloads.

I tried to pin a LESS (CSS variant) file, of which the integrity tag was ignored by Firefox and Chrome.

It seems that they follow the specification to the letter. The first version is about adding the integrity for the link and script HTML elements, but not for every attribute. The specification only mentions handling the integrity attribute for the link element when rel="stylesheet":

Whenever a user agent attempts to obtain a resource pointed to by a link element that has a rel attribute with the keyword of stylesheet

By looking at the Less website, we see that they rely on link but with rel="stylesheet/less", thus not part of the specification.

Maybe you could file an issue on their github repository for the second version?

Why is it limited to external resources?

why not add it on all browser included files (even self-hosted)?

By looking at the specification it does not seem it was part of their threat model. Here is their first goal:

Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts.

One could assume that if an attacker is able to modify a self-hosted JavaScript file, it can probably do more. Sure, it does not mean the attacker can modify the HTML part, but the attacker in their model cannot modify internal resources.

Ronny
  • 1,098
  • 8
  • 12