Open Bug 1419459 Opened 6 years ago Updated 8 months ago

Add CORS information to webRequest details objects

Categories

(WebExtensions :: Request Handling, enhancement, P5)

59 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: synzvato, Unassigned)

References

Details

(Whiteboard: [design-decision-approved][dev-ux])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171120222519

Steps to reproduce:

It's currently impossible for a WebExtension to infer CORS information from webRequest details. Without said information, there's no way for an extension to find out if a redirection is going to succeed. For example, forwarding requests that come from "script" elements with a "crossorigin" attribute to web_accessible_resources, results in fatal CORS exceptions.

1. Compare details from a cross-origin webRequest to those of a regular webRequest.


Actual results:

There is no way to infer CORS details from any of the differences between both webRequest details objects.


Expected results:

I had assumed that making the distinction would be trivial. I expected something along the lines of a "crossOrigin" property inside of the webRequest details, when applicable. I could see its value being either "anonymous", or "use-credentials".
Priority: -- → P5
Whiteboard: [design-decision-needed]
Hereby, I'd like to further clarify my initial report. All this is entirely about the various CORS-modes of web requests, which can be set by webpages; either by explicitly creating a request object and setting its credentials property [1], or by defining specific HTML attributes [2]. Extensions can modify requests, but cannot assess if changes will cause issues.

Addressing this bug would solve an issue that is currently affecting Decentraleyes. [3] The add-on points CDN-requests to local resources. Since these requests target external services, said extension could use CORS-mode metadata to find out if a redirection attempt would cause any problems. This is needed, as strict CORS-modes block "moz-extension://*" requests.

Knowing if a particular redirection should succeed is important. It allows add-ons to ignore problematic requests, and is unlikely to have any unwanted side-effects. More and more websites are starting to implement said policies, so it's becoming an increasingly large problem. Preventing page breakage is keeping Decentraleyes from supporting additional resources.

For anyone wondering if it would not be a better idea to exclude requests to web accessible resources from CORS-policies; that's probably not a good idea. I'm convinced that doing so will cause UUID leakage. [4] I believe this proposal, strikes a much better balance between functionality and security. This suffices, and should be generic enough to benefit others.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Request/Request
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes
[3] https://github.com/Synzvato/decentraleyes/issues/16
[4] https://github.com/ghacksuserjs/ghacks-user.js/issues/227#issuecomment-326682171
Severity: normal → enhancement
This bug renders the Decentraleyes add-on unusable for many users.  The current workaround (to whitelist all known sites using crossorigin script attributes) doesn't scale and is too cumbersome for manual whitelisting (which will additionally be too difficult to remove once this bug is fixed, resulting in privacy issues for all manually-whitelisted sites).

Since Decentraleyes is a featured add-on, perhaps this warrants P4 with normal priority (if not P3)?
More and more websites use content delivery networks, so the CDN servers become more interesting for hackers to replace existing scripts by malware scripts. Unfortunately only a few websites take care of security using the crossorigin restrictions.

Decentraleyes is afaik the only option to ensure that CDN scripts have not been changed. But the more people are using this featured add-on, the more developers will leave the crossorigin attributes out (or may even remove them) to ensure their website is not broken in Firefox clients.

So should the priority not (at least) be normal?

With priority P5 this issue is classified as "will never be fixed" or am I wrong? In this case you should remove Decentraleyes from the featured add-ons as you recommend an add-on that breaks valid websites. I'd really regret this...
P5 means that it's on the backlog and we'll accept patches. Currently this is waiting for a design-decision-needed meeting to discuss if this API should be added.
Hi Synzvato, this bug has been added to the agenda for the February 20, 2018 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1-edU5RRFo2TupsOW400AcTOj8yyQnXd0F7uSsqkEzck/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Hi Caitlin, and thanks for the update, and the additional details. I'm very happy to hear that the proposal will be discussed during the next WebExtensions APIs triage, and I will definitely be attending the meeting.
As more an more stuff is making its way into webrequest, we're starting to have some concern over complexity and potentially performance, so we'll want to think carefully about those.  Given that, we feel exposing this information is fine.
Whiteboard: [design-decision-needed] → [design-decision-approved]
Product: Toolkit → WebExtensions
Whiteboard: [design-decision-approved] → [design-decision-approved][dev-ux]

Sorry guys to bother, but is there any plan for resolving this issue?
Waiting now for two years. ;)
Thank you for your work and wish you best

Decentraleyes is a recommended add-on on the Mozila site, yet it breaks when sites add security features like subresource integrity? It's a bit saddening that we're still catching up with things that would have worked pre-WebExtensions.

I think the best thing to do is to basically exclude the address moz-extension:// from SOP/CORS, so that something can always be loaded from these extension storage. A bad extension does bad things with and without SOP/CORS.

(In reply to algo12 from comment #11)

I think the best thing to do is to basically exclude the address moz-extension:// from SOP/CORS, so that something can always be loaded from these extension storage.

Entries in web_accessible_resources are going to be loadable regardless of CORS settings once my patch for bug 1694679 lands.

Sub-resource integrity is another thing that we may need to revisit, but that's more tricky than CORS. SRI is tracked in bug 1321916, with no recent activity.

Status: UNCONFIRMED → NEW
Depends on: 1694679
Ever confirmed: true
See Also: → 1321916

The feature request in bug 1712096 covers the use cases presented thus far.

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