1930102 - JAGGAER SciQuest procurement site shows X-Frame-Options deny page loading after upgrade to Firefox 132

Status: UNCONFIRMED

(Web Compatibility :: Privacy: Site Reports, defect)

Description

[david.degen]

Attachment: Firefox 132 - X-Frame-Options errors_11-08-2024.pdf

Steps to reproduce:

In JAGGAER SciQuest procurement software, select a supplier tile which is embedded with X-Frame-Options. I suspect this error is related to the security fix for CVE-2024-10458.

Actual results:

Firefox throws an error:

"Firefox Can’t Open This Page

To protect your security, www.google.com will not allow Firefox to display the page if another site has embedded it. To see this page, you need to open it in a new window."

Example Console Error is:
"The loading of “https://www.google.com/” in a frame is denied by “X-Frame-Options“ directive set to “sameorigin“.

In this example, however, there is no direct link access on the webpage that can be opened in a new window, so there is no workaround.

Expected results:

In Firefox 131 or earlier, (or Chrome or Edge), the embedded supplier webpage opens without issue.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dveditz, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Daniel Veditz [:dveditz]]

This is hard to diagnose without a testcase or a public website that exhibits the problem. I'm confident it is NOT related to CVE-2024-10458 which was about camera permissions and literal <embed>, and had nothing to do with x-frame-options or <iframe>.

There used to be a button in blocked iframes that let you easily open the frame, but that could be abused to trick a user into opening content outside of security restrictions the containing page may have applied. This button was removed in Firefox 127—not 132—in bug 1888695 so I don't think that is your complaint. For debugging purposes the "workaround" is to find the url using devtools. For a normal user, opening the framed content on its own could be an attack, and many times it won't "fix" the broken web page because functionality depends on communication between the frame and the parent document.

In a similar x-frame-options block Chrome just shows a blank frame (with a dim gray sad computer icon) and never had an equivalent button. You say Chrome works, so they are not being served the x-frame-options header. I think you're saying that Firefox didn't use to get the x-frame-options error page at all, but you might be saying that it always has but you just worked around it using the button we took away in Firefox 127.

In Firefox 131 or earlier, (or Chrome or Edge), the embedded supplier webpage opens without issue.

Did you actually confirm this by trying an older copy of Firefox again? Is it possible it's a coincidence that the website changed between your last visit and when you got the Firefox update? I'm not at all familiar with this site or whether it's the sort of thing you would use daily or only once in a while.

In theory Firefox applies the exact same rules about enforcing x-frame-options: as Chrome, and we collaborate on standards-based Web Platform Tests (https://wpt.fyi) to ensure things like this. The most likely explanation is that the site is serving different content to Firefox. We would need to see what the website is serving to figure this out.

Do you use "Strict" mode for Tracking Protection? Firefox 132 started blocking 3rd party cookies in Strict mode, and that could certainly cause a website to serve us different content. For example, a framed page might redirect to a login form and those are typically served with x-frame-options. https://www.mozilla.org/en-US/firefox/132.0/releasenotes/
Could you try disabling Tracking Protection for that site or setting your default to "Standard" mode to see if the page works?

Comment 3

[david.degen]

Hi Daniel -- Thank you for your reply. I reinstalled Firefox 131 using identical privacy and security settings to confirm that the problem occurred when Firefox upgraded to 132. In Firefox 132, for the vendor pages to load, you have to disable enhanced tracking protection now, (strict protection settings can still be enabled); or use various tricks to get a page to open in a new window. In Firefox 131 (or earlier going back 8+ years), pages just opened immediately --- not even an exception list request in Firefox.