Closed Bug 825882 Opened 11 years ago Closed 4 years ago

If a website using x-frame-options to say that it does not want to be <iframe>ed, then the website should not be allowed to run as a top-level page of an app

Categories

(Core :: DOM: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
blocking-basecamp -
Tracking Status
b2g18 + ---

People

(Reporter: jsmith, Unassigned)

References

Details

See https://bugzilla.mozilla.org/show_bug.cgi?id=825388#c4.

If a website uses x-frame-options to say that it does not want to be <iframe>ed, then we should not allow the website to run as a top-level page in an app.
That's odd.  The code in nsDSURIContentListener::CheckOneFrameOptionsPolicy uses nsGlobalWindow::GetScriptableTop, precisely so this sort of thing will work, as far as I can see.

On the other hand, I'm a little confused about this bug.  The summary seems to indicate that the bug is that an app with x-frame-options _can't_ run, but comment 0 says that we should make that be the case (which implies it's not the case now).  What are the actual and expected behavior here?  Looking at the other bug you reference, it looks like the summary is probably wrong?
Component: DOM → Document Navigation
Flags: needinfo?(jsmith)
Clarified summary.

The top-level page of an app runs as the top-level docshell of its process. So whatever cross-origin detection we have won't detect the top-level page as being cross-origin in any way.

However since the page runs in a context which doesn't show the normal UI, with URL-bars and whatnot, that probably means that we should allow it to run top-level in an app.

Except the page is same-origin with the app itself that is. That way the app can set the appropriate x-frame-options headers and then rely on that it won't be run inside an iframe or inside another app. But that it can still run as part of its own app.
blocking-basecamp: --- → ?
Summary: If a website using x-frame-options to say that it does not want to be <iframe>ed, then the website cannot run as a top-level page of an app → If a website using x-frame-options to say that it does not want to be <iframe>ed, then the website should not be allowed to run as a top-level page of an app
I see.  So the code at http://hg.mozilla.org/mozilla-central/file/33064e13c3fd/docshell/base/nsDSURIContentListener.cpp#l297 or so needs to be taught about whatever setup apps are using, yes?
> If a website using x-frame-options to say that it does not want to be <iframe>ed, then the website 
> should not be allowed to run as a top-level page of an app

I'm not sure I see.  Would it be accurate to rephrase the summary as

  If a page uses x-frame-options to indicate that it does not want to be framed, then the page should not be allowed to run as a top-level app frame, unless the page's origin matches the app's origin.

?

I'm not sure that's entirely consistent with the x-frame-options header; what I described above sounds more like x-frame-options: SAME_ORIGIN, not DENY.
Jonas took care of clarifying the needsinfo request. So clearing that flag.
Flags: needinfo?(jsmith)
> I'm not sure that's entirely consistent with the x-frame-options header

IOW, an alternative is to could consider a top-level app frame to be a frame embedded inside a page with the app's origin.  Then apply x-frame-options rules as usual.

I'm not sure this is better than what I understood in comment 4, but it's an idea.
I'm starting to be less sure that this is the right solution.

Consider facebook-connect for example. I could see it wanting to use x-frame-options to avoid getting click-jacked. But it's a prime example of something that would want to be allowed to be run in an app.

Maybe the solution is to introduce some new x-frame-options value? But I'm not sure that that would work.
(In reply to Jonas Sicking (:sicking) from comment #7)
> I'm starting to be less sure that this is the right solution.
> 
> Consider facebook-connect for example. I could see it wanting to use
> x-frame-options to avoid getting click-jacked. But it's a prime example of
> something that would want to be allowed to be run in an app.
> 
> Maybe the solution is to introduce some new x-frame-options value? But I'm
> not sure that that would work.

fwiw, frame-options seems to have some degree moved over to being part of the CSP User Interface Safety spec : http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html which separates out framing from clickjacking protections (of course, this spec is fairly recent and we'd need to implement those protections). 

I have mixed feelings about a frame-options value that says 'don't allow this page to be framed, unless it's in an app', but from a security perspective, it's something the site would opt in to - checking the app and page are same origin as suggested (module the scheme) sounds alright at first thought as well.

I do think that if a site uses the existing frame-options mechanisms to block being framed, that should probably apply to apps
Ian: Note that we're not talking about being *framed* inside an app.

We're talking about getting opened as a top-level browsing context, but inside of an app.

An app is basically just a normal webpage running in a, API-wise normal, window. This window is a top-level window. The question is what should happen if that window is navigated to a webpage which sends an x-frame-options header?

The reason that a website might care that they are running as a top-level page in an app, rather than as a top-level page in a browser, is that the UI around an app is different from the UI around a browser.

In an app, there is no URL bar. Instead there is a user expectation that they are still inside some app X.
blocking-basecamp: ? → -
tracking-fennec: --- → 18+
Doug - Did you mean to set tracking-b2g+?
tracking-fennec: 18+ → ---
tracking-b2g18: --- → ?
I can do this, but we need to decide what we're doing...
I am unsure that this is an issue at all. AFAIK, x-frame-options is provided as a mechanism to prevent clickjacking. Since Apps have separate cookie jars, clickjacking is not a risk.
Ah ok, missed the subtlety here I think - we were hoping to gain a protection by re-using existing XFO headers as a mechanism to indicate that a page shouldn't run as an app? But for the reasons in comment 7 this sounds like it might break things.

I believe this bug is no longer relevant since we're not doing apps, but moving to the component that deals with XFO issues for a second opinion. I don't believe XFO was a reliable signal to prevent the original problem. Specifically, Facebook doesn't want to be framed (XFO), but if FxOS had taken off I'm sure they would have wanted to be an app. An OAUTH provider wouldn't want to be framed (XFO), but they may need to be used by apps. It's a mismatched control.

Component: DOM: Navigation → DOM: Security
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.