Bug 1647519 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

A few notes from #Fission :

Cross-process case:

1. A `ContentChild` issues `javascript:` load by calling `BrowsingContext::LoadURI` – for our example, a (forbidden) cross-process load;
2. ... or `nsDocShell::LoadURI` (or `InternalLoad`) sends `LoadURI` (or `InternalLoad`) to the `ContentParent`;
3. The `BrowsingContext` sends `LoadURI` (or `InternalLoad`) to the `ContentParent` (we need to block this with a nice error message).
4. The `ContentParent` receives the `LoadURI` and sends a `LoadURI` to another child (need to block this with `IPC_FAIL` in `ContentParent::RecvLoadURI` - `RecvInternalLoad`, in case the `ContentChild` has been compromised).
5. The `ContentChild` receives the `LoadURI` (nothing to do, with the patch, this has already been blocked in step 3. or 4.).

In-process case:

Some same-process loads may hit `nsDocShell::LoadURI` directly without going through `BrowsingContext`, and they should still reject with a sane error if the triggering principal doesn't subsume the principal of the target document.
A few notes from #Fission (thanks, kmag and nika!) :

Cross-process case:

1. A `ContentChild` issues `javascript:` load by calling `BrowsingContext::LoadURI` – for our example, a (forbidden) cross-process load;
2. ... or `nsDocShell::LoadURI` (or `InternalLoad`) sends `LoadURI` (or `InternalLoad`) to the `ContentParent`;
3. The `BrowsingContext` sends `LoadURI` (or `InternalLoad`) to the `ContentParent` (we need to block this with a nice error message).
4. The `ContentParent` receives the `LoadURI` and sends a `LoadURI` to another child (need to block this with `IPC_FAIL` in `ContentParent::RecvLoadURI` - `RecvInternalLoad`, in case the `ContentChild` has been compromised).
5. The `ContentChild` receives the `LoadURI` (nothing to do, with the patch, this has already been blocked in step 3. or 4.).

In-process case:

Some same-process loads may hit `nsDocShell::LoadURI` directly without going through `BrowsingContext`, and they should still reject with a sane error if the triggering principal doesn't subsume the principal of the target document.

Also:
@kmag "Incidentally, you probably want to report the error with rv.ThrowSecurityError(...) something like this: https://searchfox.org/mozilla-central/rev/ce21a13035623c1d349980057d09000e70669802/js/xpconnect/wrappers/AccessCheck.cpp#153
But in the case of window.open and window.location = ..., I don't think we're allowed to throw for things like this, so I think we'll just need to create the exception and report it."

Back to Bug 1647519 Comment 3