Closed Bug 1615901 Opened 4 years ago Closed 4 years ago

Origin header should not be set on OpenSearch POST

Categories

(Firefox :: Search, defect, P1)

73 Branch
defect
Points:
5

Tracking

()

VERIFIED FIXED
Firefox 75
Iteration:
75.2 - Feb 24 - Mar 8
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- wontfix
firefox75 --- verified

People

(Reporter: alex_y_xu, Assigned: daleharvey)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. navigate to https://duckduckgo.com/lite/
  2. add as a search engine
  3. set as default search engine
  4. select text, right-click, "Search DuckDuckGo Lite"

Actual results:

page displays "forbidden"

Expected results:

search results displayed

this has been reported by other users in various forums, usually resolved by switching to non-Lite. I believe this is a bug though: opensearch engines should not be sent the domain of my search origin.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
20200207195153

You can enter about:config into the address bar and set network.http.sendOriginHeader to 0

That seems to make the search results load. I'm not entirely sure what actually triggers the 403 forbidden response, since it worked fine at first in a brand new profile.

Has STR: --- → yes
Component: Untriaged → Search

I reproduced it in a new profile with Firefox 73.0 on Linux.

Assignee: nobody → dharvey

note that this is also an issue if you highlight the text and drag it to a new tab

Iteration: --- → 75.1 - Feb 10 - Feb 23
Points: --- → 5
Priority: -- → P1
Iteration: 75.1 - Feb 10 - Feb 23 → 75.2 - Feb 24 - Mar 8
Pushed by dharvey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c9d304142ff5
Dont send Origin header with context menu searches. r=ckerschb,Standard8
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75
Flags: qe-verify+

Hello,

I’ve tried to reproduce this issue in order to verify it, with different Firefox versions (73.0, Nightly from 2020-02-04, latest nightly 2020-03-20 and beta 75.0b6) on different Oses : Windows 10x64, mac0S 10.15 and Ubuntu 18.04x64. Unfortunately I couldn’t reproduce it by following the str from comment 0, the searched result was displayed properly.

Alex, could you please verify if this is fixed on latest beta? (https://archive.mozilla.org/pub/firefox/candidates/75.0b6-candidates/)

Thanks.

Flags: needinfo?(alex_y_xu)
Status: RESOLVED → VERIFIED
Flags: needinfo?(alex_y_xu)

Considering the privacy issue, and the straightforward fix, should we consider uplifting (some form of) this to 68 esr?

Flags: needinfo?(standard8)

I think that would be reasonable. Dale, do you want to see if this can be uplifted to 68 cleanly? I suspect it should be possible.

Flags: needinfo?(standard8) → needinfo?(dharvey)

[Tracking Requested - why for this release]:

As Gijs mentions, it improves privacy, fixes search engine breakage and is relatively simple

Flags: needinfo?(dharvey)

After looking at the patch on esr68, I realised that the test passed without the patch. Dale mentioned about bug 1424076, and that landed in 70.

I checked with mozregression and got:

10:31.42 INFO: Last good revision: 62286ede9f12840eb941fe849643448348704b51
10:31.42 INFO: First bad revision: c6299be2356cc2bb10f3e1e7e6f04ed2004585d3
10:31.42 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=62286ede9f12840eb941fe849643448348704b51&tochange=c6299be2356cc2bb10f3e1e7e6f04ed2004585d3

Which points to bug 1424076.

Hence, 68 isn't affected.

Has Regression Range: --- → yes
Attachment #9135517 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: