Privacy issue: Origin header sent for selected text context menu searches
Categories
(Firefox :: Search, defect)
Tracking
()
People
(Reporter: descartavel1, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- visit any url other than your default search engine, e.g. bugzilla.mozilla.org
- highlight any text
- right click and select "search <your search engine> for <highlighted words>"
Actual results:
The new tab with search results open with a request containing a referer header analogous "Origin: bugzilla.mozilla.org"
This offends rfc6454, which reserves the Origin header exclusively to signal the origin that, quoting the rfc, "origin(s) that "caused" the user agent to issue the request [...] For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request"
A user right clicking text and selecting search from the browser's own context menu, is in no stretch of imagination "caused by the origin"!
Expected results:
First, this should not have been sent for any good reason for the user.
This is completely self serving to the search engine and I can't think of a reason a developer would have spent time on it if not for being under a search engine payroll/influence.
second, selecting Strict tracking protection should have ended this behavior. It does not.
Third, changing "network.http.referer.XOriginPolicy" to a value that prevents xorigin referer[sic] would be a very clear and loud signal that the user do not wish this "feature" enabled. But alas, it still happens.
|
||
Comment 1•5 years ago
|
||
Thank you for the report.
(In reply to gabriel from comment #0)
This is completely self serving to the search engine and I can't think of a reason a developer would have spent time on it if not for being under a search engine payroll/influence.
I understand why you think this, but it is not true.
I have worked on a number of Firefox security bugs (like the one you've filed here). A lot of security issues are caused by websites being able to pretend that the user "wants" something, when it's really the website who does (privilege confusion). The user, of course, is allowed to do pretty much whatever they like, and websites are not. Part of how we track this in Firefox is via what is called the "triggering principal" - effectively, the privilege level and origin of the source of a request. As an example, anything you type in the address bar is treated as "system" principal, the highest level. By contrast, if you right click a link on a web page and open it in a new tab, the triggering principal is that of the website - after all, the website is what contains the link (and the link could be malicious, e.g. if a javascript: or data: URI that inherits the privilege level of its opener, and the website should not be able to trick the user (cf. bug 229050) to open such a link with a higher privilege level than it deserves). We've had issues in the past when this principal was incorrect ( e.g. bug 1437009 ).
Similarly, I expect that when lots of these triggering principals were added ( bug 1362034 ), we chose the originating website's privilege level for searches from the context menu from a principle of "least privilege" - this ensures e.g. that the link opens in the correct container / usercontextid, in private browsing if you're in private browsing, etc. etc., and that content on the webpage can never pretend to be more privileged than it should be. Hopefully based on the above, you can see that wasn't actually such an unreasonable assumption - and certainly nothing to do with search engine policies, but a security oriented fix that touched lots of UI points where the user can open links (we had to add these principals anywhere that loaded URLs... it was a lot of work.).
The additional header information is unfortunate, and I don't know if this was already the case in bug 1362034 - I'm pretty sure our Origin header support has changed since then, so it's possible it's a more recent regression. I expect our networking code makes decisions about whether to send such a header (or null or no Origin header at all) based on the triggering principal, and this case was not considered - the "normal" case where we open example.com from example.org will be an <a> tag on one website pointing to the other.
To confirm, the UA in comment #0 suggests that you're testing in ESR 68. Does the same problem happen in Firefox nightly and release?
Third, changing "network.http.referer.XOriginPolicy" to a value that prevents xorigin referer[sic] would be a very clear and loud signal that the user do not wish this "feature" enabled.
This pref governs the referer header, not the origin header.
Christoph, should we just change the triggering principal for the search request from the context menu to system, even though it's based on content in the page? Or do you think there's an issue with how networking is deciding to send this header? I'm a bit confused on what basis the networking code has made that decision, as it doesn't seem to happen with normal link navigations (they get a referer header, subject to the webpage + user referer policy prefs), which I would assume have the same principals attached.
|
||
Comment 2•5 years ago
|
||
We've actually just fixed this in bug 1615901 for Firefox 75. I believe it only applied to cases where a search engine used POST rather than GET (which is very few engines afaik).
I think we can probably just mark this as duplicate?
|
|
||
Comment 3•5 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #2)
We've actually just fixed this in bug 1615901 for Firefox 75. I believe it only applied to cases where a search engine used POST rather than GET (which is very few engines afaik).
I think we can probably just mark this as duplicate?
Yeah, that looks fine to me.
Description
•