Closed Bug 1593321 Opened 4 years ago Closed 4 years ago

Redirects should not be blocked by X-Frame-Options Policy

Categories

(Core :: Security, defect, P1)

72 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 --- fixed

People

(Reporter: buggyz, Assigned: ckerschb)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-active])

User Story

This bug is about a specific regression (used to work, then it didn't, tracked down to a mistake in the fix for bug 1584998) handling redirects served with an X-Frame-Options header. It is not a general "Frame was blocked by X-Frame-Options" issue. There can be _MANY_ different causes of that error page and lumping them in the same bug report is not helpful. Some issues are sites not following the specification (is the frame blocked in Chrome, Edge, Safari, too?) -- those would be "Webcompat" bugs where we'd need to work with that site, or go file an issue about https://tools.ietf.org/html/rfc7034 with the IETF or with the HTML standard.

If an embedded frame is blocked ONLY in Firefox then it could worth filing a "Core" bug like this one -- but file separate bugs about separate sites so we can investigate the individual causes on each.

Attachments

(3 files)

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

Steps to reproduce:

Updated Firefox Nightly to 72.0a1 (2019-11-01) (64-bit).

Surfed to https://www.bonnieradvocaten.nl/bereikbaarheid

This site has Google Maps Embedded in the webpage and uses the:
"x-frame-options: sameorigin" header set.

Actual results:

The Embedded Google Maps portion of the page (https://www.bonnieradvocaten.nl/bereikbaarheid) shows the following error:

Blocked by X-Frame-Options Policy

An error occurred during a connection to maps.google.com.

Nightly prevented this page from loading in this context because the page has an X-Frame-Options policy that disallows it.

Expected results:

As far as i know, and:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
seems to confirm this, the "x-frame-options: sameorigin" should prevent other pages from loading "www.bonnieradvocaten.nl" within a iframe.

Setting the header should not prevent maps.google.com from loading from within the page as it currently does.

I don't know what happened with the styling of this bug, my apologies.

I cleaned up the styling of your report.

Component: Untriaged → Security
Product: Firefox → Core

@Emma Humpries
Thanks A Lot.

See Also: → 1584998

Confirming regression. The new behavior basically prevents any page with X-Frame-Options: sameorigin from framing other content.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ckerschb)
Keywords: regression
Regressed by: 1584998
Assignee: nobody → ckerschb
Status: NEW → ASSIGNED
Flags: needinfo?(ckerschb)
Priority: -- → P1
Whiteboard: [domsecurity-active]
Attached image xfo_google_maps.png

There is definitely something wrong with our implementation of XFO, but I don't know what it is at this point. Here is what I figured out so far:

  • Visiting https://www.bonnieradvocaten.nl/bereikbaarheid indicates that this document is using the response header XFO: sameorigin plus a CSP including frame-ancestors. So XFO would be ignored on that page because of frame-ancestors, but any of that has nothing to do with the problem here.

  • The page then includes an iframe (see exact source of the iframe inclusion underneath) from https://maps.google.com. The response header of that iframe load also includes XFO: SAMEORIGIN. (see attached screenshot). Please note that there is no CSP which would render the XFO obsolete.

  • So now framing https://maps.google.com/ into a top-level document originating from https://www.bonnieradvocaten.nl/bereikbaarheid is cross origin in my opinion, so our current implementation blocks it.

  • Here is the deal however:
    ** Prior Bug 1584998 -> the framing was allowed
    ** Google Chrome -> framing is allowed
    ** Safari: framing is allowed

Looping in Dan and Jonathan because I think the current blocking makes sense given the parameters I just listed, but ultimately something must be off, because other browser and our previous implementation allowed it. Additionally, why would google maps not be allowed to be framed and why would no one have figured that out so far.

Clearly something must be wrong with our implementation, but what? Any suggestions?

%---snip---
<iframe frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://maps.google.com/maps?q=Bonnier%20Advocaten%2C%20Saltshof%2C%20Wijchen&amp;t=m&amp;z=12&amp;output=embed&amp;iwloc=near" aria-label="Bonnier Advocaten, Saltshof, Wijchen"></iframe>

Flags: needinfo?(jkt)
Flags: needinfo?(dveditz)

Maybe it has something to do with redirects? In Firefox 69, the final iframe seems to load "https://www.google.com/maps/embed?origin=mfe&pb=!1m4!2m1!1sBonnier+Advocaten,+Saltshof,+Wijchen!5e0!6i12", which has no X-Frame-Options headers.

The XFO seems to only be applied on a 302 request. I suspect we should be ignoring this where as before the XFO code wasn't getting CORS redirects in the child process perhaps?

The only other differences in the code I can see that we changed are not catering for mozbrowser and using the document principal instead of the node principal.

Flags: needinfo?(jkt)

Rrrrh, there is even a wpt test for it:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/x-frame-options/redirect.sub.html#18

That's what you get when you trade a new error page over wpt test coverage :-(

Our implementation is observing http response headers of a channel that in fact returns a 301, so the response headers should be ignored.

Flags: needinfo?(dveditz)
Pushed by ncsoregi@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/19fb0b6103be
Ignore XFO on channels that will be redirected. r=jkt,dragana
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

I believe I've encountered this issue on Google Translate with Firefox 75.0 (64-bit) on Windows 10 1909. This URL should demonstrate the problem: https://translate.google.com/translate?hl=&sl=auto&tl=en&u=https%3A%2F%2Fntu.primo.exlibrisgroup.com%2F

I am facing this issue in ubuntu with Firefox 75.0 64.
Through these websites and similar phone simulators, I cannot browse the internet:
https://www.responsinator.com/
or
http://iphone5simulator.com/

error:
Blocked by X-Frame-Options Policy
An error occurred during a connection to www.google.com.
Firefox prevented this page from loading in this context because the page has an X-Frame-Options policy that disallows it.

I'm having this issue with 75.0 (64-bit) on Ubuntu 19.10.

I'm using the popular Joomla CMS on a localhost Apache 2 server. To insert images it uses a modal that loads in images via an iFrame. The iFrame content is blocked by X-Frame-Options Policy. The iframe content is hosted on the same localhost server.

I'll try and figure it out and see if I can solve it myself.

Blocked by X-Frame-Options Policy
This page has an X-Frame-Options policy that prevents it from being loaded in this context.
Firefox prevented this page from loading in this context because the page has an X-Frame-Options policy that disallows it.

https://drive.google.com/file/d/1C-Xd-rD166A4FDZK2XtXwu2Ocy3TejcZ/view

I noticed in the code of the Firefox error message there is a comment that says...
ERROR ITEM CONTAINER (removed during loading to avoid bug 39098)
...so I'm not sure if that helps.

Joomla! Version Joomla! 3.9.18 Stable [ Amani ] 21-April-2020 19:30 GMT
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

I tried the extension mentioned there...
https://addons.mozilla.org/en-US/firefox/addon/ignore-x-frame-options-header/
...and it does solve the immediate problem.

Why is it, that you cannot detect these errors with your script? I'm totally against errors that are impossible to handle, like the error discussed in the issue.

If the serving web site blocks frames, that's fine with me, but firefox should allow me to detect that fact in my runtime script, instead of allowing those errors to be shown on the page, with no ability to detect them using javascript.

Ideally, the main window should be informed about this block when it is detected and there should be some way to catch the error, or some event triggered. This way, you can replace the blocked content with a link to the page that won't allow frames. The way it is, is ridiculous.

Is this behavior by spec? Where is the correct place to complain about this, respectfully?

This bug report should be re-opened.

How do I fix this???

And now this question was posted in the support forum :

https://support.mozilla.org/en-US/questions/1274313

I also have this issue, the extension helps with websites but if other extensions use an iframe then it doesn't help.
Please re-open the case!

Firefox Nightly version 78.0a1 (2020-05-09)

.... and another user just posted here :

https://support.mozilla.org/en-US/questions/1274313

.... and another one :

https://support.mozilla.org/en-US/questions/1274313#answer-1315697

Please, re-open this bug report !!!

McCoy is right this needs to be reopened, I use Firefox nightly as a daily driver and the bug has been present a while now, super annoying I can't use certain extensions with nightly because of it. Please reopen before this bug is pushed to beta/stable.

McCoy, Mark, I am happy to re-consider opening the bug if you could help us by reporting some steps to reproduce the errors you are encountering. Particularly useful would be:

  • What page you are visiting when encountering the problem?
  • What addons do you have installed?
  • What error is reported to the web console?
Flags: needinfo?(markg095)
Flags: needinfo?(amylovendaal)

@ Christoph Kerschbaumer :
It would be great if this bug report was re-opened ! Thank you in advance !
The additional information has to come from those users who are stuck with this problem though - I am merely drawing attention to the fact that we get so many reports about this problem on the support forum.
Maybe going over the thread(s) I linked to will help ?
Hopefully Mark can provide some additional information (?)

Flags: needinfo?(amylovendaal)

(In reply to McCoy from comment #26)

Maybe going over the thread(s) I linked to will help ?
The problem is that we can not reproduce the issues reported there on our end, hence it's hard to find a fix.

Hopefully Mark can provide some additional information (?)
Yeah, let's hope of the best!

I really want to have any issues resolved as quickly possible myself - thanks for your contribution!

Johann Hofmann (and another user) just posted here :

https://support.mozilla.org/en-US/questions/1274313

The Ignore X-Frame-Options Header firefox add-on works fine for most cases. However, if you want to disable it on your Windows or Linux web servers then here's the procedure: https://www.helpmegeek.com/blocked-by-x-frame-options-policy-error-firefox/

..... and users just keep reporting this issue :

https://support.mozilla.org/en-US/questions/1289337

Again : please, reopen this bug report !

Still encountering this on Google Translate, FF 77 on MacOS.

Encountered this just trying to LOGIN to my account at "The Brain" via their desktop app and my default browser, Firefox.

A bizarre bug that provides no useful information to an end-user which does not occur if the user sets Chrome or Safari to default browser - should not be ignored by support because they do not have a immediate reproduction provided by an END-USER. Or am I wrong?

Apologies - but this is something that embarrasses anyone trying to defend Firefox as the more elegant or reliable browser choice.
If an ADD-ON called "Ignore X-Frame-Options Header" fixes the issue - is this really something that an end-user is expected to understand and solve? The current behavior does not present Firefox in a very good light from an end-user perspective.

How many more complaints must come in before the assignee takes responsibility, either to dig-in and reproduce or solicit help from other engineers? Should the end-user be responsible? Should they provide their credentials, i.e. login, passwords and external apps if such are involved?

I've seen dozens of posts, in multiple forums, which describe this as a Firefox issue solved by switching browsers.

Sorry - I am on current release, Firefox 75.0.1 64-bit WIndows.

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #25)

  • What page you are visiting when encountering the problem?
    Just got hit with this issue and found my way here through Google.

Several examples have been provided. For your convenience, here it is restated:

https://www.responsinator.com/?url=https%3A%2F%2Fmozilla.org

  • What addons do you have installed?

No addons. I did a fresh install of Firefox 77.0.1 (64-bit) on Windows 10. It also happens on Windows 7 with the same version of FF, the only addon there is ABP.

  • What error is reported to the web console?

The loading of “https://www.mozilla.org/en-US/exp/” in a frame is denied by “X-Frame-Options“ directive set to “DENY“.

I'm against those of you who are advocating some add-on extension to address this problem. The issue needs to be addressed at a level that allows the developer to detect and handle this error in client-side javascript (that get served during initial page load) and not from some add-on extension (that many users are unwilling or afraid to install). Extensions are an "after the fact" hack to the problem and the problem needs to be accessible by run-time try/catch client-side javascript!

The extension may be ok, but since I cannot catch the error, with runtime client-side javascript, I cannot even recommend that extension to the user in the event that the error occurs.

Attached image ff_screenshot.png

Stephen, Francis, Lonnie, thanks for your reports. X-Frame-Options it's an HTTP respsonse header which allows web sites to signal the browser that their page should not be framed (appear in an iframe). This Security mechanism allows web sites to protect their users against click jacking attacks. What appears like a browser problem, is in fact Firefox keeping you safe. However, we are working on some UI improvements (see answer below) which allows the user to understand why content is not displayed.

(In reply to wes from comment #35)

Several examples have been provided. For your convenience, here it is restated:
https://www.responsinator.com/?url=https%3A%2F%2Fmozilla.org

I tried the linked web page and Chrome is logging the same error to the console not allowing the load to happen.

I agree, the end user should not have to deal with such problems and not being left confused. To that end we upgraded our user experience to show the end user when a web page signaled the browser not to display the web page in a frame. Further introducing a link which allows the page to be loaded as a top-level page (instead of in a frame), which eliminates any potential click-jacking attack, hence keeping Firefox users safe but still allowing them to display the page they want to visit (see screenshot).

User Story: (updated)
Summary: Blocked by X-Frame-Options Policy → Redirects should not be blocked by X-Frame-Options Policy
Has Regression Range: --- → yes

Clearing out my ni? queue with super old ni? requests which rendered unnecessary in the meantime.

Flags: needinfo?(markg095)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #38)

I agree, the end user should not have to deal with such problems and not being left confused. To that end we upgraded our user experience to show the end user when a web page signaled the browser not to display the web page in a frame. Further introducing a link which allows the page to be loaded as a top-level page (instead of in a frame), which eliminates any potential click-jacking attack, hence keeping Firefox users safe but still allowing them to display the page they want to visit (see screenshot).

Christoph, I consider this a great improvement and a sensible default. However, as the developer, I'd still like to be able to detect and override this default with my own customized page being displayed in this frame. My biggest complaint about this bug is that I cannot detect when it occurs via Javascript. That's the root cause of the issue. Had I been able to detect this error, I could display something that is indeed allowed to be displayed in the frame. I'm fine with Firefox blocking a page going into a frame. What I'm not fine with, is the fact that Firefox keeps this between only Firefox and the End User. The developer's script should be able to detect when a frame has this blocking, so that the developer of the page can display something in the frame that is indeed allowed instead. One thing the developer might display is very similar to the sensible default you've provided: a notification that the page that was supposed to be displayed here doesn't allow their page to be embedded into another website and to click here if they'd like to open the page in its own tab. However, this is not the only possible legitimate action that can be taken.

In my opinion, it is Firefox's job to enforce not allow the page to be embedded, but it is the developer of the page's responsibility to decide what to do about that block. Maybe, since the site doesn't permit embedding, I want to provide instructions as to how the user can request that sight to start allowing the embedding: If enough users request that, and the destination site sees the usefulness of that request, they may change their mind and allow embedding after-all (removing the block entirely). Or, maybe I want to redirect my page to an entirely different page due to the one frame being blocked. There are numerous way you might want to handle a blocked frame (not just one).

When a block like this occurs, there needs to be an event I can subscribe to to detect it before it happens. I need some type of ability to detect these blocks when they happen, and do something that IS INDEED allowed instead.

Again, the behavior has become a sensible default, but we still lack the ability to detect the block in javascript. That's what I want the ability to do. Had I had it, I could have provided something similar to what you've done, without it breaking the style and purpose of my page.

It may be Firefox's job to block, but it isn't Firefox's place to decide what to do about that block. A sensible default is fine, but if the developer wants to detect the block and do something else, that should be allow too. So bottom-line: block it, but allow me to detect it with javascript when you do.

You need to log in before you can comment on or make changes to this bug.