Ready for Trial: Block external protocol in sandboxed iframe.

92 views

Skip to first unread message

Arthur Sonzogni

unread,

Sep 30, 2021, 7:59:17 AM9/30/21

to blin...@chromium.org

Summary

Gates sandboxed iframe navigation toward external protocol behind any of: - allow-popups - allow-top-navigation - allow-top-navigation-with-user-activation (+ user activation) Motivation: Sandboxed iframe navigation are allowed, because they stay within the iframe. However when they lead to the opening of an external application, this can be seen as a new popup or a new top-level navigation somehow. Extending sandbox scope here, resolves issues developers/users had with malicious advertisers.

Blink component

Blink>SecurityFeature>IFrameSandbox

TAG review

We think this is not needed here. Handling external applications is at the boundary of the web platform. This is a security improvement.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This prevents sandboxed iframe from navigating or redirecting users toward an external application. Goal is to break malicious ads. There is an inherent and intended compatibility risk. In a first step, this will only record metrics to ensure the number of blocked requests is relatively small. We are going to work to drive those numbers down (target <0.0005% PageLoad), or ensure they are dominated only by malicious actors, before shipping the enforcement.

Enterprise policy will be supported. Interoperability risk is that other browser vendors do not implement these restrictions. Firefox is working on enforcing it as well.

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/581) Firefox would like to enforce it as well, once the compatibility risk question has been resolved.

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html) (pending)

Web developers: Strongly positive. Amazon & multiple independent security researcher have filled feature request: - https://crbug.com/1148777 - https://crbug.com/1250415 - https://github.com/whatwg/html/issues/2191

Ergonomics

N/A

Activation

N/A

Security

This is intended as security positive.

Goals for experimentation

I don't expect a huge interest in trying this feature. I wanted to submit an intent-to-implement instead, but it wasn't proposed in the interface, when filling out a "Web developer facing change to existing code".

The goal is making this intent public and gathering potentially some feedback about the proposed specification.

Ongoing technical constraints

N/A

Debuggability

A Devtools console error message is shown to developers when the sandbox blocks the external application.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Android WebView is purposefully excluded. It does not provide a way to handle external protocol on its own, but let the embedding Android application to intercept the request. We do not block the request and let the embedding app its full powers here. We don't want to risk breaking existing Android applications.

Is this feature fully tested by web-platform-tests?

This is at the boundary of the web platform (external apps). This is not observable from within a document. So it is not possible to have WPT.
There are non-WPT tests.

Flag name

SandboxExternalProtocolBlocked

Requires code in //chrome?

Yes, this is mostly inside //chrome, so that Android Webview can stay unaffected.

See change.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1253379

Launch bug

https://crbug.com/1253405

Estimated milestones

DevTrial on desktop

DevTrial on android

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5680742077038592

This intent message was generated by Chrome Platform Status.

Reply all

Reply to author

Forward

0 new messages