Open Bug 1465094 Opened 6 years ago Updated 2 years ago

Consider removing domain restrictions for fetch/XMLHttpRequest

Categories

(WebExtensions :: General, enhancement, P3)

60 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: robwu, Unassigned)

References

Details

(Keywords: sec-other)

Attachments

(1 file)

In an attempt to defend against privilege escalation via Sync, bug 1415644 introduced some restrictions for extensions at some Mozilla domains via extensions.webextensions.restrictedDomains:

(i) Extensions cannot run scripts or observe any request from pages at these domains.
(ii) Extensions cannot observe or modify requests to these domains, even if originating from non-restricted pages.
(iii) Extensions cannot send non-CORS requests to these domains.


I believe that restrictions (ii) and (iii) are unnecessary, and that the list of domains is too long:

- Restriction (i) guarantees that extensions cannot execute code in restricted pages, not directly and not indirectly via requests (system requests and requests from restricted domains are already hidden). Cache poisoning cannot be done through webRequest. Therefore the CDNs in the list can be removed.

- Restriction (iii) breaks a legitimate use case (bug 1450649).

- Restriction (ii) and (iii) are not needed for AMO, because the AMO restriction was added to prevent unintentional scripting (https://bugzil.la/1415644#c22).

- Bug 1415644 was about restricting access to FxA.
  FxA does currently not use cookies, but localStorage and sessionStorage. Therefore requests not initiated by FxA do not contain sensitive data, and it should be safe to drop restrictions (ii) and (iii).
  (and if we do, then we should recommend to not introduce cookies as a fallback at https://github.com/mozilla/fxa-content-server/issues/6114 )



The fact that cookies are not used by FxA is good news, because the restrictions are not sufficiently enforced for cookies, and can be bypassed in three ways:

   1. Reading cookies using the cookies API (and proxy requests through an external server).

   2. Reading domain cookies by scripting/connecting to a non-restricted subdomain.
      E.g. reviewers.AMO can read domain cookies from AMO.

   3. Writing domain cookies via a non-restricted parent domain (this is a session fixation attack).

Fully enforcing the restrictions for cookie has disadvantages (each point describes the disadvantage of patching the issue that I identified above):
- Hiding restricted domains in the cookies API reduces the effectiveness of cookie add-ons (and the built-in one was removed in bug 1348223).
- Restricting scripting access to subdomains of restricted domains breaks reviewers.AMO. This domain only exists to allow reviewers to use additional add-ons for their workflow.
- Blocking access to the main domain (e.g. mozilla.org) may break too many useful add-ons (e.g. MDN, BMO).

... so I believe that we should continue to not enforce domain restrictions for cookies. This implies that restriction (iii) is not needed either, and most likely restriction (ii) can be removed too.



If there is a strong reason to keep restriction (ii) and (iii), then we should also perform a permission check when the Host request header is modified in the webRequest API. Otherwise an extension can connect to another domain at the same server and rewrite the Host header.
Here is a demo of the domain fronting technique that bypasses restriction (iii):
https://github.com/Rob--W/crxviewer/commit/c4a4d4e23e757d19cfa669edb5f446e28f427e1f
Here ia a self-contained PoC for bypassing the restricted domains using domain fronting.

Load the extension in Firefox, and the extension will try to read https://addons.mozilla.org/robots.txt

Expected result ("Without domain fronting"):
Failed to fetch: TypeError: NetworkError when attempting to fetch resource.

Actual result ("With domain fronting"):
(the actual response of AMO/robots.txt)
aswan: can you take a look at this?
Flags: needinfo?(aswan)
Whew, this bug covers a whole bunch of loosely related things.
I spun out bug 1467523 for the Host rewriting issue.
Flags: needinfo?(aswan)
Can someone please give this bug a useful summary?
With the fork of bug 1467523, this bug can now focus on one issue: The list of domain restrictions is too large, and fetch/XHR requests are unnecessarily blocked.

Script execution in over-privileged pages (FxA, AMO) should be blocked, but the resources themselves are not special (not any more special than e.g. google.com).

(I haven't checked <img crossorigin>, but these should not be subject to domain restrictions either.)
Summary: Remove domain restrictions for non-sensitive requests and/or properly enforce domain restrictions → Fetch/XMLHttpRequest should not be constrained by extension domain restrictions
Summary: Fetch/XMLHttpRequest should not be constrained by extension domain restrictions → Consider removing domain restrictions for fetch/XMLHttpRequest
Product: Toolkit → WebExtensions
Priority: -- → P3
In bug 1467523 (landed in Firefox 63 and Firefox ESR), validation was added to enforce the domain restrictions on the request header.

I can kind of bypass those by taking advantage of the fact that the server is accessible via two host names:
https://addons.mozilla.org/
https://addons.mozilla.org./ (with period).

The bypass has no negative effect on Firefox, as Firefox treats them as distinct domains:

I checked and confirmed that "addons.mozilla.org." does not have special behavior in Firefox:
- It does not receive cookies meant for "addons.mozilla.org"
- It does not get access to AddonManager.
- It is not subjected to the domain restrictions.
- Clicking on an Install button at the domain-with-dot does not immediately activate an install prompt, but a warning as if it is a third-party site. 

In the absence of progress in this bug and https://github.com/mozilla/addons-server/issues/9118 , I will use this work-around in my extension source viewer add-on so it can continue to view the source code of Firefox add-ons.
Since we're talking about loosening restrictions, not a current bug, does this need to remain hidden?
Keywords: sec-other
Bug 1467523 is a clone of this bug and took care of fixing the sec bug that I reported here.
The remaining work here is to loosen the restrictions for a specific use case.

But because of the PoC, this bug should be hidden until bug 1467523 is public.
Group: toolkit-core-security → firefox-core-security

Opening after related bug 1467523.

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

Attachment

General

Created:
Updated:
Size: