1430257 - [meta] Stop treating nested URIs as same-origin with their innermost URI

Status: NEW

(Core :: Security, enhancement)

Description

[:Gijs (he/him)]

(largely copied from bug 1171853)

It seems there's not that many nested URI schemes left. While some of those rely on being same-origin with their inner, that likely isn't the ideal behaviour.

To change this, we need to get rid of the existing nested URIs that might rely on that in some way. In particular:

- remove remote JAR support (bug 1427726)
- stop nesting about: URIs (bug 1228118)
- (maybe) stop having nested moz-icon URIs (they don't really need to be nested, and it's doubtful much will break if we unnest them - file: listings and so on already use the non-nested variants; equally, I don't think making them non-same-origin with the nested URI will break anything that we intend to work).
- remove the IO Service's newNestedSimpleURI exposed method (bug 1430237) so no new surprise consumers will end up being created.
- figure out what the story is with jar: URI usage on android. Nick, can you help with that? How is jar:jar used, and does gecko resolve it or does android java code do so, or something else? In particular, do we ever load jar:<anything> as a toplevel document in the browser content or as an image/resource that we then need access to (as opposed to e.g. a script file reference, or loading the same content via chrome:// or resource:// URIs)?

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Would this effect the origin of view-source URLs?  I'm curious how it would effect bug 1317036.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Would this effect the origin of view-source URLs?

Yes.  That is one of the main goals, in fact.

> I'm curious how it would effect bug 1317036

That's using URIs, not principals, right?  It could still unnest the view-source URI if it wanted to...

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Well, what will the origin of "view-source:http://example.com" be?  Will it be exactly that vs "http://example.com"?

Comment 4

[:Gijs (he/him)]

(In reply to Ben Kelly [:bkelly] from comment #3)
> Well, what will the origin of "view-source:http://example.com" be?  Will it
> be exactly that vs "http://example.com"?

Yes.

Comment 5

[Nick Alexander :nalexander [he/him]]

> - figure out what the story is with jar: URI usage on android. Nick, can you
> help with that?

I can try.  We should get snorp and jchen to comment too; adding NIs.

 How is jar:jar used, and does gecko resolve it or does
> android java code do so, or something else?

jar:jar is used to load resources from out of the Android omnijar from Java, so we definitely resolve jar:jar in Java code; but it's all done with Java ZipReader instances, so it doesn't see these issues.

I see very few clear jar:jar references that Gecko would resolve directly, but you can see where we've used jar:jar explicitly at https://searchfox.org/mozilla-central/source/mobile/android/components/BrowserCLH.js#22-36.  More below.

 In particular, do we ever load
> jar:<anything> as a toplevel document in the browser content or as an
> image/resource that we then need access to (as opposed to e.g. a script file
> reference, or loading the same content via chrome:// or resource:// URIs)?

The explicit usage above is _always_ via resource://android/, so maybe that already solves your problem.

And you can see that there just aren't that many uses in our tree: https://searchfox.org/mozilla-central/search?q=resource%3A%2F%2Fandroid&path= but that _most_ of them are images; and that none of them are toplevel anythings.

Now, I expect resource://android to be much more important in GeckoView, since it allows to pull things out of the Android assets folder in the APK, and that's how GeckoView consumers will bundle HTML/CSS/JS.  (That is, they definitely won't load assets from an omnijar since they won't be building an App-specific omnijar at all.)  However, I can't find the code that does this in geckoview anymore!  Perhaps the world has moved on and I'm unaware.

Comment 6

[(inactive) Jim Chen [:jchen] [:darchons]]

Yeah Nick is right. Looks like inside Gecko, we only load jar:jar: indirectly via resource: or chrome:, so it shouldn't be affected by this bug.

Comment 7

[:Gijs (he/him)]

Nika, Christoph and I recently had the misfortune to be re-acquainted with all the ways in which nested URIs in general and view-source in particular are... odd.

From some discussion, it would seem that the way forward is likely still to first stop using nested URIs for about:, and then pursue this bug to ensure that nested:foo:... is not same-origin with foo:... anymore. We'd probably want to land such a change at the start of a cycle, as the testing story around view source and other consumers is still not great, and we'd want to be sure that fission-related processing targeting of view-source URIs continues to point at the right URIs.

The about: protocol work in bug 1228118 should be pretty shovel-ready though, and hopefully not too complex - the migration of indexeddb data (bug 1228118 comment 1) was tackled in bug 1438367. So in theory it should be as simple as removing a bunch of complexity around the existence of moz-safe-about:.