Open Bug 1321916 Opened 8 years ago Updated 2 years ago

Web Extensions need a way to update the integrity attribute associated with web requests

Categories

(WebExtensions :: Request Handling, enhancement, P3)

Product:
WebExtensions
Component:
Request Handling
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: francois, Unassigned)

References

Details

(Whiteboard: [design-decision-approved]triaged)

Content blockers which replace certain JS resources are exposed via integrity attributes on the script elements: http://blog.bugreplay.com/post/153861574674/fkadblock-how-publishers-are-defeating-ad https://github.com/sitexw/FuckAdBlock/issues/54 If we give extensions a way to update the integrity attribute, then they could avoid their modifications getting detected and blocked by the browser. (Via https://twitter.com/mikewest/status/804592156103114752)
Maybe the APIs could "drop" the integrity metadata from a request, thus making the response automatically succeed the integrity check.
Whiteboard: [advisory-board]
Whiteboard: [advisory-board] → [advisory-board] design-decision-needed
Whiteboard: [advisory-board] design-decision-needed → [advisory-group][design-decision-needed]
After further discussion, we thought this seemed like a good idea, but wanted to check with dveditz.
Component: WebExtensions: General → WebExtensions: Request Handling
Flags: needinfo?(dveditz)
Priority: -- → P3
Whiteboard: [advisory-group][design-decision-needed] → [design-decision-approved]
Whiteboard: [design-decision-approved] → [design-decision-approved]triaged
As long as everyone understands this is a never-ending arms race... If they actually change or remove the integrity attribute in the DOM then site script could detect that. The detection script could even be inline script (onload handler?) and ultimately hard to prevent, plus sites going this route now can't adopt a strict CSP policy so we've made the ecosystem worse. What APIs are the web extensions using for this? If it's an API that lets the extension modify the effective integrity for the request without changing the DOM that seems fine. I've seen a lot of badly coded extensions so (barring good arguments) I'd prefer making the extension provide a substitute integrity hash rather than giving them the ability to drop integrity. For local resources integrity doesn't matter, but for remote resources--especially ones loaded insecurely--it can matter a lot. If we require a substitute integrity hash then extensions might want a property that lets them know integrity is in use so they know when they have to come up with one. I don't know if that's feasible with the API we've got. So far I've only been talking about the replace/redirect case. In the future sites might use the "require integrity for" CSP feature that would require integrity on new elements inserted by an extension. If the extension is injecting content that changes based on user auth or other params (think of the crash charts injected by Bugzilla Socorro Lens, or even something as simple as gravatars) this could get awkward fast. Page would have to XHR/fetch the content, calculate hash, then inject the element as a blob:/data: url with the calculated integrity. But of course the integrity here is doing no good whatsoever since it was calculated after the point the content might have been modified! I guess I'd want to see the proposed mechanism but this seems reasonable. The user has installed the extension to make certain modifications and we should let it do that.
Flags: needinfo?(dveditz)
Severity: normal → enhancement
Product: Toolkit → WebExtensions
Depends on: 1706073

So I raised Bug: 1720891 before remembering this one.

Overview:

Firefox doesn't permit an extension to redirect to a local resource hosted within the extension if the resource has an SRI integrity attribute. This is required to provide user choice such as removing tracker banners or invalid warnings to the user without breaking the site.

This has come up in some of our site breakage where a website was doing the following:

let script = document.createElement('script');
script.onload = function() {
  initWebsite()
};
script.onerror = function() {
  alert("You shall not pass");
};
script.integrity = 'sha256-xjwKUY/NgkPjZZBOtOxRYtK20GaqTwUCf7WYCJ1z69w=';
script.crossOrigin = 'anonymous';
script.src = 'https://cdnjs.cloudflare.com/ajax/libs/fuckadblock/3.2.1/fuckadblock.min.js';
document.head.appendChild(script);

STR:

  1. Install https://addons.mozilla.org/en-GB/firefox/addon/duckduckgo-for-firefox/
  2. Go to: http://privacy-test-pages.glitch.me/privacy-protections/surrogates/

Actual results:
The test fails and the console contains the following error:
Failed to find a valid digest in the 'integrity' attribute for resource 'https://google-analytics.com/analytics.js' with computed SHA-256 integrity 'W7MQTBlQ7AcSERmsI4GYNsKy6kKOSY92wU+99GKTjSw='. The resource has been blocked.

Expected results:
"google-analytics.com/analytics.js broken integrity" to pass and no SRI warning in the console.

Note: The test purposefully uses an invalid SRI so it always fails when the extension isn't loaded.

(In reply to Daniel Veditz [:dveditz] from comment #3)

So far I've only been talking about the replace/redirect case. In the future
sites might use the "require integrity for" CSP feature that would require
integrity on new elements inserted by an extension.

This got removed since Dan's comment, I don't think there is any desire to have require-sri-for anytime soon.

My proposal here is that a carve out to be added to the SRI code specifically when the extension redirects to a local moz-extension:// resource.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.