Bug 231727 – New spec: Block external protocol handler in sandboxed frames

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Arthur Sonzogni]

Implementation bug about a new specification:
spec: https://github.com/whatwg/html/pull/7124#pullrequestreview-778826909
whatwg/html bug: https://github.com/whatwg/html/issues/2191

Developers are surprised that sandboxed iframe can navigate and/or
redirect the user toward an external application.

General iframe navigation in the sandboxed iframe are not blocked
normally, because they stay within the iframe. However they can be seen
as a popup or a top-level navigation when it opens an external
application. In this case, it makes sense to extend the scope of sandbox
flags, and block malvertisers.

This feature gates access to external protocol from sandboxed iframe behind any of:
- allow-popup
- allow-top-level-navigation
- allow-top-level-navigation-by-user-activation + UserGesture.

[Radar WebKit Bug Importer]

<rdar://problem/84498192>

[Chris Dumez]

Created attachment 443258 [details]
Patch

[Tim Horton]

Comment on attachment 443258 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=443258&action=review

Vaguely worried about ads that want to pop to the App Store. Also about third party app compatibility. But no concrete examples of either.

> Source/WebKit/ChangeLog:13
> +        an external apps.

“An external apps”

> Source/WebKit/UIProcess/WebPageProxy.cpp:5359
> +        WEBPAGEPROXY_RELEASE_LOG_ERROR(Process, "Ignoring request to load this main resource because it has a custom protocol and comes from a sandbox iframe");

“Sandboxed”? Also should we log to the inspector too?

[Chris Dumez]

Created attachment 443305 [details]
Patch

[Chris Dumez]

Created attachment 443323 [details]
Patch

[Chris Dumez]

Created attachment 443438 [details]
Patch

[Chris Dumez]

The iOS API test failure is caused by Bug 232769.

[Chris Dumez]

Created attachment 443478 [details]
Patch

[Chris Dumez]

Ping review?

[Brent Fulgham]

Comment on attachment 443478 [details]
Patch

R=me

[EWS]

Committed r285501 (244025@main): <https://commits.webkit.org/244025@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 443478 [details].

[Arthur Sonzogni]

Hi Chris,

Some data I gathered on Chrome about enabling this.
This would impact ~0.015% pages.

Among them, a good quarter is triggered from https://teams.microsoft.com with the msteam: protocol. They have been notified about it here:
https://github.com/whatwg/html/issues/2191#issuecomment-952283644
and we hope this will contribute to reduce the number of impacted pages.

I just wanted to let you know this is still not enforced by default in Chrome, so you may get some websites complaining about it. On the other side, I am expecting a part of this is coming from malicious ads, but I don't have any estimations, only some reports that this is maliciously used in the wild.

Getting Safari to ship this would greatly help me enabling this in Chrome too, so I am very happy! I just wanted to warn you about the risk and I will let you decide if 0.015% is acceptable.