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