2033905 - Redirecting search result pages to a page packaged in a WebExtension breaks searching from highlighted text's context menu

Status: RESOLVED FIXED

(WebExtensions :: General, defect)

Description

[Jacob Winters]

Steps to reproduce:

Minimal repro:

1. Install the extension at https://github.com/jacobwinters/firefox-declarativeNetRequest-redirect-repro.
2. Set Google as your default search engine.
3. Search from the address bar. Redirect is successful.
4. Right click some text > Search Google for "...". Blank tab opens with the unredirected URL showing in the address bar. Ctrl-L, Enter fixes it.

Real-world repro:

Set Kagi as your default search engine using the 2nd method on https://help.kagi.com/kagi/getting-started/setting-default/firefox-desktop.html. (You need to set a SERP URL with a ?token= query parameter, which is one way of logging in automatically.) Install and enable the Kagi Privacy Pass extension, which is an alternate way of authenticating. It uses a declarativeNetRequest rule to bounce requests with token parameters off a bundled page that strips the parameter. Searching from highlighted text's context menu will break the same way as in the minimal steps to repro. (Aside: I've been running into this for months in my Tor Browser setup and am overjoyed to have finally stumbled across the cause.)

How I found it:

We'd like to add a new mode to the Privacy Pass extension where it affects incognito tabs only. I've almost got it working by setting excludedTabIds to a list of all non-incognito tabs and calling updateSessionRules every time browser.tabs.onCreated sees a new one, but there's a race condition where the onCreated handler runs too late when a tab is created and immediately goes to a search page before the extension can react. I'm trying to solve the race condition by making a rule to redirect all Kagi searches on tabs the extension hasn't seen yet through a bundled trampoline page so that the extension has time to update the rules, but now every context menu search is hitting this bug.

Actual results:

Browser console shows "Security Error: Content at moz-nullprincipal:{299c2c90-16d8-467e-b52f-b91d9ee59e3d} may not load or link to moz-extension://381bd49f-144b-4c89-ae7b-2c1e5d374581/destination.html."

Expected results:

Redirect should succeed regardless of how we ended up at its source URL.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Search' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mark Banner (:standard8)]

Sounds more like an issue specific to WebExtensions.

Comment 3

[vcarciu]

I used the minimal steps to reproduce and I was able to reproduce the issue. Marking bug as NEW.

Comment 4

[Rob Wu [:robwu]]

Attachment: Bug 2033905 - Permit access to web-accessible resources with <all_urls>

When an extension resource is exposed via web_accessible_resources with
"matches" including "<all_urls>", it should be exposed to any URL.
This did not happen for sandboxed documents, because those have a null
principal that serializes to a URL with the "moz-nullprincipal" scheme.

To get this to work, permit requests from schemes unknown to
MatchPattern when matches contains <all_urls> (and *://*/*).

This patch also includes test coverage for requests from file:-URLs,
because that did not exist before, and a naive implementation (that
accepts any request if MatchesAllWebUrls is true) could inadvertently
permit requests from non-sandboxed file:-URLs. The unit tests ensure
that this does not and will not happen.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0c0b2f5d79d2
https://hg.mozilla.org/integration/autoland/rev/ae1db915e702
Permit access to web-accessible resources with <all_urls> r=willdurand

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/ae1db915e702