Open
Bug 1455360
Opened 7 years ago
Updated 4 years ago
Prevent extensions from hijacking the search page
Categories
(WebExtensions :: Request Handling, enhancement, P3)
WebExtensions
Request Handling
Tracking
(Not tracked)
NEW
People
(Reporter: mstriemer, Unassigned)
References
Details
Extensions are allowed to set a search engine which the user can control, but an extension could also overwrite the search engine in a malicious way by redirecting the request to another page.
The tabs.update() [1] API should disallow redirecting from a search URL, as should redirects in the webRequest API.
[1] https://searchfox.org/mozilla-central/rev/59a9a86553e9bfd9277202748ff791fd9bc0713b/browser/components/extensions/parent/ext-tabs.js#643
Comment 1•7 years ago
|
||
This is really much easier said than done. There are a bunch of ways for extensions to do this.
We can probably set some special metadata on search requests from the search bar and about:home, and prevent extensions from redirecting or canceling them. We'd have to be careful to also prevent them from doing things like setting refresh headers, though.
The tabs.update() case is less easy. With some effort, we can probably associate the inner window of the of the tab with the search request, and prevent extensions from updating it without a user input handler. The real problem, though, is that we *can't* prevent them from loading content scripts into the search page. That's pretty much a non-starter. And that content script can redirect the page anywhere the page itself could.
We could try to be clever and detect when the extension is trying to redirect the page vs. when the page itself is, but there are always ways around that.
The best I can come up with, really, is to detect any script-initiated redirects shortly after the page loads, and prompt users to make sure they really want to navigate. At least for built-in providers, we should be able to be reasonably sure that isn't breaking any legitimate functionality of page scripts.
Anyway, I'm all for making this as hard for malicious actors as possible. It just won't be all that easy.
See Also: → 1299571
Updated•7 years ago
|
Product: Toolkit → WebExtensions
Comment 2•7 years ago
|
||
Aha, this is basically how my extension ( https://addons.mozilla.org/en-US/firefox/addon/classical-search-bar/ ) works. I am not sure how you consider it as hijacking. And I cannot understand how a searching page should be different from other pages.
Anyway, besides "redirect", using an full viewpoint <iframe> to "replace" the searching result, or even re-write the whole document should be enough for most so-called hijacking extensions, though the address bar is kept without change.
> The best I can come up with, really, is to detect any script-initiated redirects shortly after the page loads, and prompt users to make sure they really want to navigate. At least for built-in providers, we should be able to be reasonably sure that isn't breaking any legitimate functionality of page scripts.
Not really. Searching "!g searchTerms" by built-in duckduckgo would cause a "script-initiated redirects shortly after the page loads" by design.
Updated•4 years ago
|
Severity: normal → N/A
Priority: P2 → P3
You need to log in
before you can comment on or make changes to this bug.
Description
•