Intent to Implement and Ship: Restrict history navigations if navigation occurs from a sandboxed iframe

[Dave Tapuska]

Contact emails dtap...@chromium.org Explainer

https://github.com/whatwg/html/issues/880 Design docs/spec Specification:

https://html.spec.whatwg.org/multipage/history.html#traverse-the-history-by-a-delta

https://github.com/whatwg/html/pull/4787

Spec note

There is a pending issue tracking the wording of the timing of reading the sandbox flags. Chrome's proposed implementation is to read the sandbox flags in the browser process at time the history navigation is to occur which matches the current spec wording.

TAG review Depending on how you read the specification it was prevented before the recent specification changes but no vendor implemented it. We've added some clarification to the specification. Other browser vendors agree that preventing this is ideal. I don't believe a TAG review is required. Summary If a history navigation originates from a sandboxed iframe without the top level navigation permission and it navigates a frame outside of itself, prevent it. Navigations that change the frame itself should be allowed. Motivation Sandboxing an iframe should prevent an iframe from having effects outside of itself. History APIs seem to bypass this restriction and it is agreed this is a hole in sandboxing. Risks

Interoperability and Compatibility There is some risk with shipping this feature however it is well within limits. Chrome collected data from stable: 0.0013% of all page navigations result in a navigation outside of a sandboxed iframe 0.006% of all page navigations result in a navigation inside of a sandboxed iframe So this will prevent 0.0013% of navigations. I believe this is acceptable risk.

See the

https://chromestatus.com/metrics/feature/popularity#SandboxBackForwardAffectsFramesOutsideSubtree

https://chromestatus.com/metrics/feature/popularity#SandboxBackForwardStaysWithinSubtree

All browsers currently allow the navigation but there is desire from other vendors to prevent these types of navigations.

Firefox: Public support (https://github.com/whatwg/html/issues/880#issuecomment-217907128) Edge: No public signals Safari: No public signals Web developers: No signals Ergonomics Unfortunately the history API will not throw an exception when this fails because the history API is not synchronous nor does it return a promise. Security This should help prevent navigations caused by a sandboxed iframe that the top level document did not anticipate.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes Tests are provided in the implementation: https://chromium-review.googlesource.com/c/chromium/src/+/1729530 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5726441989734400

[Charlie Reis]

The risk here (and the reason I asked for a Blink Intent to Ship during review) is that it makes the history API even more unpredictable in sandboxed iframes.  That might be ok, but it's a compatibility impact, so I think it's worth getting approval for.

More specifically, an iframe doesn't have control over whether another frame in the page adds a session history item, so it doesn't know whether calling history.back() will work or not.  Consider these two scenarios:

One:

1) Top-level document A loads sandboxed iframe B.

2) A does a pushState to #a2.

3) B does a pushState to #b2.

4) B does a history.back() and gets back to its original state.

Two:

1) Top-level document A loads sandboxed iframe B.

2) B does a pushState to #b2.

3) A does a pushState to #a2.

4) B does a history.back().

Scenario Two isn't great either before or after Dave's proposed change.  Today, A goes back to its original state but B stays on #b2, and B would have to do another history.back() to get back to its original state.  After the proposed change, B's history.back() does nothing, and it's stuck and can never get back to its original state unless A cooperates.

This is all a consequence of the legacy back/forward behavior that operates on joint session history items rather than being frame-specific, which isn't something we can change at this point.

Are we ok with making history.back() do nothing in cases like this, rather than affecting other frames?  If so, I'm happy to proceed with reviewing Dave's CL.

Thanks!

Charlie

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZVTCV%2BbFmkxgYhCrzkkuHJqr2f%3DvFdDwcQpiPSYqg9S7A%40mail.gmail.com.

[Alex Russell]

Thanks for all the detail, Charlie & Dave! Appreciate the quantified impact.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Chris Harrelson]

LGTM1

The situation with these frames and the history API is sad, I agree, but the benefits seem to outweigh any possible cost, which will affect a very small number of pages.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBZnTd4stJTJt3eoF8MPS2BnxUx-rjB76g0TJib7iPfHww%40mail.gmail.com.

[Daniel Bratell]

LGTM3 (per weekly API owner meeting, and with Alex and Chris' two LGTM1s)

We did note the lack of a good history API alternative and it might be good to get started at such a project sooner rather than later (hint to anyone who reads this).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_rbDXfLFEnoYxo3TYgi9a%2BnStgaFffeg0u_JqVhN7b-A%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */