1798954 - Consider disallowing MV3 extensions to redirect intercepted webRequest to data URLS and to require an explicit manifest permission to be granted

Status: NEW

(WebExtensions :: Request Handling, task, P3)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

An earlier version of the patches attached to Bug 1786919, we were looking into disallowing to MV3 extensions to redirect intercepted webRequests to data URIs, and eventually allow it only when a specific separate manifest permission is being explicitly requested.

We decided to evaluate that in a separate bugzilla issue, and this issue is tracking the additional work to look into that.

As a note that is worth keeping in mind when we get back to this:

• Bug 1434357 introduced channel.loadInfo.allowInsecureRedirectToDataURI = true related to redirects to data URIS here in WebRequest.jsm to fix a regression on uBlock Origin due to preventing redirects to data: urls

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1798954 - Disallow to MV3 webRequest listeners to bypass CORS checks on data: redirectUrl. r?mixedpuppy!

Comment 2

[sdaniele3]

Would this be a "hidden" permission (one that doesn't prompt users)? I can't imagine explaining the nuances of this issue to end-users in a small pop-up box. If it's not shown to the user and is just for better addon review I think it's a reasonable option.

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to sdaniele3 from comment #2)

Would this be a "hidden" permission (one that doesn't prompt users)? I can't imagine explaining the nuances of this issue to end-users in a small pop-up box. If it's not shown to the user and is just for better addon review I think it's a reasonable option.

That is also matching my current perspective about it and I think it is going to be very likely the case, but I haven't yet discussed about this with the rest of the team.

In the meantime, if you have some other use case (besides the one we can derive from uBlock use of it) from the extensions that you have worked on, feel free to describe some example of the use cases per your knowledge in new comments on this issue.

That may also be helpful with assessing what this bug should cover (and also double-check if some enhancement bugzilla issue that we have already filed may cover the same use case without involving allowing redirect to data URIs).

Comment 4

[sdaniele3]

I have an extension that allows the user to specify a URL and then a redirect URL. It's mostly used for overriding Javascript / CSS files of websites with personalized ones. The extension doesn't particularly care what the redirect URL is and thus data: URLs can be used. There's even an "upload" button that'll allow the user to upload a file and the extension generates a data: URL to use. An alternative that I have toyed with is to create a webRequest.StreamFilter and just write out the data rather than redirecting.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to sdaniele3 from comment #4)

I have an extension that allows the user to specify a URL and then a redirect URL. It's mostly used for overriding Javascript / CSS files of websites with personalized ones. The extension doesn't particularly care what the redirect URL is and thus data: URLs can be used. There's even an "upload" button that'll allow the user to upload a file and the extension generates a data: URL to use. An alternative that I have toyed with is to create a webRequest.StreamFilter and just write out the data rather than redirecting.

I see, it sounds like for that particular (probably common enough, I bet uBlock use case doesn't differ that much in purpose) the main difference of resorting to webRequest.StreamFilter as an alternative approach is that the request would need to hit the network first, while redirecting to a data URI could happen before the request ever got to the actual server.

I think that Bug 1712096 is tracking an enhancement that would cover the use case you are describing (and so I'm going to also link it as a see also to this bug).

Comment 6

[brunoais]

An example addon that does this kind of work is LocalCDN.
It has two issues:
Attributes in <script> tags:

• crossorigin
  • "The crossorigin attribute prevents the replacement because the destination does not match the requested one. "
• integrity
  • "To save disk space and to deliver more frameworks LocalCDN upgrades a framework" [...] " The integrity check will fail because the hash values for e.g. jQuery 1.10.1 and jQuery 1.12.4 are different."

It uses filterResponseData in order to remove crossorigin and integrity.
It then has been using chrome.webRequest.onBeforeRequest and returning

    return {
        'redirectUrl': chrome.runtime.getURL(targetDetails.path + fileGuard.secret)
    };

To provide the URL to the incorporated resource.

I hope with the addition of this permission, the ability to ignore crossorigin and integrity can be added to the browser as part of web filter.

Comment 7

[Rob Wu [:robwu]]

(In reply to brunoais from comment #6)

An example addon that does this kind of work is LocalCDN.
It has two issues:
...

Bug 1712096 sounds like a better fit for your use case than this bug. Your use case is comparable to the Decentraleyes add-on, and CORS and SRI have also been mentioned. data:-URLs are not the ideal tool for your problem. E.g. they can be blocked by CSP.

Comment 8

[brunoais]

(In reply to Rob Wu [:robwu] from comment #7)

(In reply to brunoais from comment #6)

An example addon that does this kind of work is LocalCDN.
It has two issues:
...

Bug 1712096 sounds like a better fit for your use case than this bug. Your use case is comparable to the Decentraleyes add-on, and CORS and SRI have also been mentioned. data:-URLs are not the ideal tool for your problem. E.g. they can be blocked by CSP.

Not my extension but understood. Thank you.