Html: Disable custom protocols in sandboxed iframe

[shhnjk]

Currently, spec allows use of custom protocols in sandboxed iframe. Which could be used to escape sandbox (see https://www.brokenbrowser.com/abusing-of-protocols/) or launch application from sandboxed iframe (mailto:, acrobat:, etc). I think custom protocols should be disabled in sandboxed iframe.

Related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1322925
https://bugs.chromium.org/p/chromium/issues/detail?id=329000

[annevk]

cc @whatwg/security

[mikewest]

I wouldn't be terribly sad if we locked this down to some extent in sandboxes. We'd need to collect some metrics regarding protocol usage inside sandboxed frames; I imagine it's low, though it probably breaks some enterprise app-launching mechanisms and ads use cases that navigate to specific app store entries (and it seems like we could deal with those by tying it to a sandbox flag).

[bzbarsky]

Definitely need data.

Also, "custom protocols" could mean at least two things: (1) protocols delegated to the OS and (2) protocols registered with https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers. Do we want to treat them identically?

[jonathanKingston]

Also, "custom protocols" could mean at least two things

The risks are likely pretty similar in terms of security right?

Would allow-top-navigation permit the sandbox iframe doing this also?

[annevk]

The risks are likely pretty similar in terms of security right?

Not really, one causes navigation within the browser, the other launches native code, potentially in a compromising manner (there have been a number of attacks like this on iOS, iirc).

[jonathanKingston]

We have had exploits via feed:// which probably wouldn't considered native but handled through a completely other code path to normal navigations.

Would there be a risk we would then expose when a browser has a client on mailto rather than gmail?

[bzbarsky]

The risks are likely pretty similar in terms of security right?

As Anne says, no, because registerProtocolHandler bits are all in-browser. That said, should we make sure we sandbox the resulting page?

We have had exploits via feed://

That's a third case: (3) non-standard protocols supported by the browser directly

or so...

Would there be a risk we would then expose when a browser has a client on mailto rather than gmail?

Yes.

[jonathanKingston]

That's a third case: (3) non-standard protocols supported by the browser directly

I also think this might be an edge case we can ignore, given that I just removed it and registering pages into odd code paths like this should be closed where possible.

As Anne says, no, because registerProtocolHandler bits are all in-browser. That said, should we make sure we sandbox the resulting page?

Well they would have to be top level navigations anyway? I don't know 100% how we handle all these cases.

[bzbarsky]

given that I just removed it

Browsers still support all sorts of non-standard protocol bits (about:, chrome:, etc, etc).

Well they would have to be top level navigations anyway?

That's orthogonal to sandboxing. Just like a window.open from a sandboxed page ends up being sandboxed, though toplevel.

[gijsk]

As a first step, could we block navigations to any non-same-protocol, non-http(s)/ws(s) URIs that do not originate from user interaction?

[patrickkettner]

just chiming in with Edge feedback
We _would_ implement this if added to the spec, though not for a while. If we did implement, we would almost certainly add a group policy as a switch

[mthiesse]

I think allow-popups-to-escape-sandbox would be the right attribute for allowing sandbox-escaping external protocols.

Here's an example for Android that launches the calculator app from a sandboxed iframe: https://mthiesse-test.glitch.me/external-protocol.html

[annevk]

I think if you can navigate the top-level browsing context (be it auxiliary or top-level of current) it's fine, but in general we should stop supporting navigating embedded browsing contexts to non-fetch schemes. (And we should act as if Cross-Origin-Opener-Policy happened. Either due to the non-fetch scheme or the redirect to the non-fetch scheme.)

[annevk]

5289 might obviate the need for this somewhat.

[mikewest]

I'm supportive of doing something with regard to limitations on navigations to non-fetch schemes in nested contexts. It's probably worth adding some telemetry to track that? @mthiesse might know if we already have histograms in Chromium?

As a more narrow, short-term step: what would y'all think about adjusting https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-url-scheme to at least take sandbox flags into account, and to disallow external handling of a protocol during navigation unless allow-top-navigation or allow-popups is present, or if both allow-top-navigation-by-user-activation along with transient activation?

[johannhof]

Hey @mikewest,

I'm supportive of doing something with regard to limitations on navigations to non-fetch schemes in nested contexts. It's probably worth adding some telemetry to track that? @mthiesse might know if we already have histograms in Chromium?

@trikolon and I have been looking at this on the Firefox side recently and we're also very interested in restricting external protocol navigations further, especially in iframes. For example we've implemented our version of the permission prompts that Edge folks previously added to Blink (and would like to wire them up with Permissions Policy, see #6111). We're working on other ways to reduce annoyance and attack surface by requiring user activation more often and I'm happy to chat about that if you're interested (maybe in a separate issue).

We have also added telemetry in the 85 release (and are currently adding some more) so we'll have data for Firefox in the coming weeks.

As a more narrow, short-term step: what would y'all think about adjusting https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-url-scheme to at least take sandbox flags into account, and to disallow external handling of a protocol during navigation unless allow-top-navigation or allow-popups is present, or if both allow-top-navigation-by-user-activation along with transient activation?

From Firefox side we think that this is a good step and would implement this change, assuming that our telemetry doesn't hint at massive breakage (which doesn't seem likely).