Closed Bug 1484699 Opened 6 years ago Closed 5 years ago

Can bypass SRI on stylesheets with the same URI.

Categories

(Core :: DOM: Security, enhancement, P3)

Product:
Core
Component:
DOM: Security
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1205143

People

(Reporter: emilio, Unassigned)

References

Details

(Keywords: sec-low, Whiteboard: [domsecurity-backlog]) 

While investigating the root cause of bug 1484690, I realized of a potential security bug which shares its root cause...

Currently SRI metadata is stored in the StyleSheetInfo, which can be shared across stylesheets. We store there the 

Thus if I have something like:

  <link rel="stylesheet" href="evil.css">
  <link rel="stylesheet" integrity="<something>" href="evil.css">

We should forbid the second load, but right now we don't, and we just reuse the same stylesheet as the first load.

We store there the referrer policy and co. as well, but those are safe since we key the loads off `URIPrincipalReferrerPolicyAndCORSModeHashKey`.

I think `URIPrincipalReferrerPolicyAndCORSModeHashKey` should also account for SRI.

I'm not sure of whether this has a huge potential as a sec bug, given you need to have a pending load for the sheet on the first place. But it looks somewhat bad that two sheets with different attributes ends up sharing the same Inner.
See Also: → 1484690
Group: core-security → dom-core-security
So as an attack, if you could inject a reference to the modified file before the legit one with an integrity check then you could bypass the integrity protection.

Integrity is mostly to protect against attacks on 3rd party server content, whereas this would require both that attack _and_ this attack directly on the user's use of the page referencing the resource. Seems like it's not going to come up all that much as a useful technique.
Keywords: sec-low
Priority: -- → P3
Whiteboard: [domsecurity-backlog]
Having thought about this some more, this isn't an issue with SRI.

- You have a stylesheet loaded from a URL that might have been modified (e.g., CDN compromise)

You either have two loads to the file, one with and one without integrity tag: You've made a mistake and we can't help you.
If that's not the case, the load was injected by an attacker. In this case, you have an XSS problem and SRI can't help you.

I'm leaning towards WONTFIX.
I think websites that want to tackle theseissues might want to look into CSP require-sri-for directive, though we don't ship it (bug 1265318).
We should probably just add SRI stuff to the hashtable key we use here.

Hm, is bug 1205143 just a public version of this bug?

Flags: needinfo?(emilio)

Looks like that.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(emilio)
Resolution: --- → DUPLICATE
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.