[css-nav-1] hostile iframes

[frivoal]

To prevent hostile third party iframes (e.g. ads) from hijacking and trapping the focus, the spatpav events (and possibly APIs, althouh I'm less sure about that) should not be available by default in cross origin iframes.

The top-level document should have a way of turning them back on for iframes it trusts.

[Malvoz]

This could be a feature policy, e.g:

allow attribute:
<iframe src="https://example.com" allow="spatnav">

or in a header field:
Feature-Policy: spatnav 'self' https://example.com;

Alternatively spatnav could be enabled by default for all sources in CSP's frame-src (and object-src) fetch directives? But that would limit control of trusted sources to only iframe and object respectively. There is the drafted navigate-to navigation directive, but I'm not totally sure how that works.

And although CSP is good practice, it would force developers to enable CSP to provide spatial navigation for iframed content. Which probably isn't ideal?

[frivoal]

@Malvoz Thanks for the feedback.

The feature policy approach looks nice to me, but I am not an expert in this area, and don't have all the background needed to pick the best way forward.

I'm going to leave this issue open for a while, and hope to gather feedback from more people.

[annevk]

Feature Policy makes sense for this (for enabling something that's by default disabled).

Is there an attack vector in the other direction? Whereby the embedder can direct the navigation such that it makes clickjacking easier?

[frivoal]

@annevk with the possible exception of window.navigate(), I don't see what spatnav APIs can do that the .focus() method couldn't. It can influence where the focus goes, but within a single document, authors are already free to move it wherever.

For window.navigate(), I suppose that it would be possible, knowing the layout of an other site, to put that site in an iframe, use .focus() to move the focus in the embedder to a focusable element that is near particular interesting click target in the embeddee, and then use window.navigate() to get that element focused. However, It only gets the element focused, it does not click/activate it.

I don't believe that merely focusing an element is a security vulnerability, but maybe I just lack imagination.

If we do want to curtail this, we could do it with 2 steps:

1. navigating towards an iframe always focuses the iframe, rather than its content. This is already the case if the iframe is scrollable, but we could make non scrollable iframes focusable as well.
2. unlike manual navigation, window.navigate() cannot move the focus from an iframe to its content, and is a noop (or throws an exception) if you try.

That would limit the usefulness of window.navigate() in general, and in particular make it insufficient to drive the test suite.

[jihyerish]

I agree with the feature policy is a good approach to solve the security issue in spatial navigation.
By default, the focus can move to the iframe elements which are the same-origin.
But for the iframe with spatial-navigation feature is given to * for the allow attribute (Feature Policy API), the focus can move inside the cross-origin iframe elements.

Detailed approach for the feature policy would be as below:

---

Default policy: spatial-navigation 'self'

Feature-Policy HTTP header

A page can declare the spatial navigation feature in its HTTP headers as follows:

Feature policy: spatial-navigation 'self'

It means that only same-origin iframe elements are allowed for the spatial navigation.

iframe allow attribute

The feature can be specified for a single iframe element using allow attribute as below:

<iframe src="https://example.com..." allow="spatial-navigation 'none'"></iframe>

This will block the spatial navigation feature for the top-level and nested iframe elements.

[frivoal]

Issue migrated to w3c/csswg-drafts#3390