Closed Bug 1213827 Opened 9 years ago Closed 8 years ago

CSP frame-ancestors breaks firefox os apps

Categories

(Firefox OS Graveyard :: Simulator, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: freddy, Assigned: ethan)

References

Details

Attachments

(2 files)

Firefox OS loading browser windows "app frames" breaks when pages use frame-ancestors that do not explicitly include "app://*".

STR:
- Get a nightly Firefox OS simulator (see here for taskcluster links https://groups.google.com/forum/#!msg/mozilla.dev.fxos/YFM8fpSxBkU/GI-fPLzSAwAJ)
- open mobile.twitter.com

I have reproduced locally with a simple PHP file that sends frame-ancestors with and without app://

Maybe we should internally allow app:// ?
Christoph, is this something you can take a look at?
[Blocking Requested - why for this release]:

This means twitter mobile website (and any other website that has a "frame-ancestors" csp directive) are currently broken on FxOS which seems to be an unacceptable regression I think.
blocking-b2g: --- → 2.5?
Needinfo'ing Paul, he said he was finding an owner.
Flags: needinfo?(ptheriault)
(In reply to Frederik Braun [:freddyb] from comment #1)
> Maybe something like
> https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.
> cpp#1116 would work.

That sounds like a reasonable approach to me. In general I think it would make sense to have some kind of seperate CSP functionality for B2G. It would be great if do not stuff all the B2G related CSP stuff into the current implementation. I think when creating a CSP we can distinguish based on the principal whether we run in browser mode or not and based on that we could instantiate special B2G classes from within the csp-parser. E.g. host matching needs to be some special B2G-path matching, and also this problem is B2G specific.
Assignee: nobody → ettseng
blocking-b2g: 2.5? → 2.5+
Flags: needinfo?(ptheriault)
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #5)
> (In reply to Frederik Braun [:freddyb] from comment #1)
> > Maybe something like
> > https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.
> > cpp#1116 would work.
> 
> That sounds like a reasonable approach to me. In general I think it would
> make sense to have some kind of seperate CSP functionality for B2G. It would
> be great if do not stuff all the B2G related CSP stuff into the current
> implementation. I think when creating a CSP we can distinguish based on the
> principal whether we run in browser mode or not and based on that we could
> instantiate special B2G classes from within the csp-parser. E.g. host
> matching needs to be some special B2G-path matching, and also this problem
> is B2G specific.

Well in this case, I dont think this is b2g specific. This is Browser API specific I think, not app:// specific. Am I correct in thinking that what should happen here is that <iframe mozbrowser> should be treated as top-level frames?

 (PS b2g is the main user of the browser API, but its also used for browser.html.)
Attached image twitter_in_aries.png
I opened "mobile.twitter.com" in the browser of Aries phone, and it works normally.
I used the build on 2015/8/3.
Does that mean frame-ancestors works in browser app before?

I will try to make a latest build and try to see if I can reproduce this bug.

=== Environment Information ===
Build ID               20150803203029
Gaia Revision          8dba2077f5e7137253fbb3faf10cd0b5f7da25c2
Gaia Date              2015-08-02 18:58:07
Gecko Revision         n/a
Gecko Version          42.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.xiaole.20150803.202023
Heres a PoC ethan: http://misuse.co/csptest.php 

This doesn't load in b2g browser. Theres another UX bug here too, which i will raise.
This screenshot demonstrates the problem. (simulator 3.0)
For desktop browsing we stop checking at the same-type docshell, that is, when we get to a chrome context. Not just a chrome-privileged "content" docshell, although "chrome://" urls get an explicit whitelist on top of that.

Since everything in b2g happens in content docshells (of varying privileges) we should consider <iframe browser> to be the top level at which we stop checking. I mean a real mozbrowser set by an app that has the privilege to do so, not just some content trying to trick us by adding an otherwise-ignored attribute.
(In reply to Paul Theriault [:pauljt] from comment #9)
> Created attachment 8676704 [details]
> failure to load a page in b2g browser
> 
> This screenshot demonstrates the problem. (simulator 3.0)

Paul, since you already have everything set up, can you post the output from the browser console by any chance? I assume there is a way you can access that information for b2g builds, right? That would help us narrow down the problem.
Flags: needinfo?(ptheriault)
In the tab you dont get the CSP error, but you do get the error that about:neterror doesnt have a translation for the CSP error. See below:

10:28:44.927 L10nError: "This page has a content security policy that prevents it from being loaded in this way." not found in en-US in about:neterror?e=cspBlocked&u=http%3A//misuse.co/csptest.php&s=neterror&c=UTF-8&f=browser&m=app%3A//system.gaiamobile.org/manifest.webapp&d=This%20page%20has%20a%20content%20security%20policy%20that%20prevents%20it%20from%20being%20loaded%20in%20this%20way. 
    at reportMissingEntity (about:neterror?e=cspBlocked&u=http%3A//misuse.co/csptest.php&s=neterror&c=UTF-8&f=browser&m=app%3A//system.gaiamobile.org/manifest.webapp&d=This%20page%20has%20a%20content%20security%20policy%20that%20prevents%20it%20from%20being%20loaded%20in%20this%20way.:1399:261)1 about:neterror:1399:261
Flags: needinfo?(ptheriault)
Note that this bug does NOT reproduce on aries (z3c) dogfood build with the ID of "20151007074930", so I'm guess it was a regression _after_ 7th of oct. Im flashing at the moment to try a nightly developer build.
(In reply to Paul Theriault [:pauljt] from comment #13)
> Note that this bug does NOT reproduce on aries (z3c) dogfood build with the
> ID of "20151007074930", so I'm guess it was a regression _after_ 7th of oct.
> Im flashing at the moment to try a nightly developer build.

Ok so (finally) got a nightly build working and I don't have this bug occur. Frame ancestors seems to work as expected. 

STR:

1. Load the following URLs:

a) http://misuse.co/csptest.php  -> loads fine
b) http://praw.nz/frame.html (frames the first url) -> frame doesnt load due to CSP

So I think this is actually fixed, but I dont know why.

Freddy can you double check on a recent build, otherwise i'm closing this as a WFM.

The only thing I can think that fixed this, might be the origin refactoring we did as part of the next security model. But that's a massive guess. We should probably try in mulet or a recent b2gdesktop build too.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(fbraun)
Resolution: --- → WORKSFORME
I also verified with the latests build (2015/10/22) on Aries-KK.
I tried both http://misuse.co/csptest.php and https://mobile.twitter.com/.
The result is the same as comment 14, the frame-ancestors directive works as expected.

So, this bug once happened in the time window between 2015/8/3 and 2015/10/22.
But we don't why it happens and why it is resolved.

Paul and Fred, do we have any test case to cover this scenario?
If not, I suggest we should add a test case for this to catch potential regression in the future.
Flags: needinfo?(ptheriault)
(In reply to Ethan Tseng [:ethan] from comment #15)
> But we don't why it happens and why it is resolved.
But we don't know why it happens and why it is resolved.
Well, I still get this problem using the latest simulator. Maybe this is a bug in the simulator?
Status: RESOLVED → REOPENED
Flags: needinfo?(fbraun)
Resolution: WORKSFORME → ---
(In reply to Frederik Braun [:freddyb] from comment #17)
> Well, I still get this problem using the latest simulator. Maybe this is a
> bug in the simulator?

I have tried the simulator but not the latest.
Let me try it later.

Could you also verify this bug on a FxOS phone?
Did not test on a phone at all.
If this only affect simulator I dont think it needs to block. I dont know when simulator was last updated.
blocking-b2g: 2.5+ → ---
Flags: needinfo?(ptheriault)
By the way-  im not sure that the simulator is even being maintained any more. The date in the settings app of the simulator says april, and its clearly an old build. So im not sure there is much point in solving this bug.

If we want to confirm in a non-device build then I would suggest either mulet, or the emulator.
(In reply to Paul Theriault [:pauljt] from comment #21)
> By the way-  im not sure that the simulator is even being maintained any
> more. The date in the settings app of the simulator says april, and its
> clearly an old build. So im not sure there is much point in solving this bug.
> 
> If we want to confirm in a non-device build then I would suggest either
> mulet, or the emulator.

Just FYI that I tested this in today's Mulet build and it is blocked as expected, so Im going to close this.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → INVALID
(In reply to Paul Theriault [:pauljt] from comment #21)
> By the way-  im not sure that the simulator is even being maintained any
> more. The date in the settings app of the simulator says april, and its
> clearly an old build. So im not sure there is much point in solving this bug.


I was using a nightly build, see comment 0.
Status: RESOLVED → REOPENED
Component: DOM: Security → Simulator
Product: Core → Firefox OS
Resolution: INVALID → ---
This bug is B2G-specific. I think we don't need to fix it anymore.
Status: REOPENED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: