Blocked by X-Frame-Options Policy (extensions)
Categories
(Core :: DOM: Security, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | verified |
People
(Reporter: remtanmajitenshi, Assigned: ckerschb)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [domsecurity-active])
Attachments
(2 files)
STR:
- Install https://addons.mozilla.org/en-US/firefox/addon/to-google-translate/
- Open extension popup
AR:
Blocked by X-Frame-Options Policy
An error occurred during a connection to translate.google.com.
Nightly prevented this page from loading in this context because the page has an X-Frame-Options policy that disallows it.
ER:
Extension popup should work.
Updated•5 years ago
|
It is 72 branch, regressed by Bug 1584998. Same as Bug 1593321 but not fixed with it.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Reproduced the initial issue using an old Nightly build 72.0a1 (build id: 20191111100226) using Windows 10.
Verified - Fixed in Nightly 72.0a1 (2029-11-22) and latest Nightly 76.0a1 (build id: 20200403063228) using Windows 10 and Ubuntu 18.04.
But this works only for the first load. If you navigate, it will not work anymore.
Comment 9•5 years ago
|
||
(In reply to Qwerty from comment #1)
It is 72 branch, regressed by Bug 1584998. Same as Bug 1593321 but not fixed with it.
I just tested on Firefox 71 and XFO wasn't bypassed either. Could you share the reproduction steps to show that XFO can be bypassed in Firefox 71 but fails on Firefox 72?
I'd like to explore the possibility to remove the ability to automatically bypass XFO in extensions, and fall back to requiring extensions to opt in via the webRequest API instead, as you're already doing in your add-on.
Reporter | ||
Comment 10•5 years ago
|
||
(In reply to Rob Wu [:robwu] from comment #9)
I just tested on Firefox 71 and XFO wasn't bypassed either. Could you share the reproduction steps to show that XFO can be bypassed in Firefox 71 but fails on Firefox 72?
Same as in bug description. Installing extension (Version 4.0.6 works) and opening popup. I used mozregression and it pointed me to bug 1584998 back then and today.
INFO : Narrowed inbound regression window from [cd45360f, d7c5b5d3] (3 builds) to [cd45360f, d5bee3db] (2 builds) (~1 steps left)
DEBUG : Starting merge handling...
DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=d5bee3db1b4f0ce5ff876f08230336022ae7d8ab&full=1
DEBUG : Found commit message:
Bug 1584998: Make x-frame-options work with fission enabled. r=jkt,farre,johannh,flod
Differential Revision: https://phabricator.services.mozilla.com/D50588
DEBUG : Did not find a branch, checking all integration branches
INFO : The bisection is done.
INFO : Stopped
as you're already doing in your add-on.
It's not my extension btw.
Comment 11•5 years ago
|
||
I can reproduce in that version with fission.autostart
= true,
but with fission.autostart
= false (default on non-Nightly), it is not reproducible.
Bug 1584998 fixed an actual bug; XFO on regular websites didn't work either (e.g. try to load www.mozilla.org on example.com via the devtools).
Comment 12•5 years ago
|
||
(In reply to Rob Wu [:robwu] from comment #9)
I'd like to explore the possibility to remove the ability to automatically bypass XFO in extensions, and fall back to requiring extensions to opt in via the webRequest API instead
So, this fix is for me not really useful and if you want to remove it, i don't have a problem with it.
Because i'm already removing the x-frame-options header from the response (like what the other add-ons are doing).
Comment 13•5 years ago
|
||
Thanks. The patch has been reverted in 77 - https://hg.mozilla.org/mozilla-central/rev/a9df87dcb391
Updated•3 years ago
|
Description
•