Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-nav-1] hostile iframes #3390

Closed
frivoal opened this issue Dec 3, 2018 · 6 comments

Comments

@frivoal
Copy link
Collaborator

commented Dec 3, 2018


Migrated from WICG/spatial-navigation#58
Originally created by @frivoal on Tue, 29 May 2018 08:05:56 GMT


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.

@frivoal

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 3, 2018


Migrated from WICG/spatial-navigation#58 (comment)
Originally created by @frivoal on Wed, 29 Aug 2018 08:35:26 GMT


@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.

@frivoal

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 3, 2018


Migrated from WICG/spatial-navigation#58 (comment)
Originally created by @annevk on Fri, 10 Aug 2018 12:01:12 GMT


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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 3, 2018


Migrated from WICG/spatial-navigation#58 (comment)
Originally created by @Malvoz on Thu, 07 Jun 2018 23:14:35 GMT


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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 3, 2018


Migrated from WICG/spatial-navigation#58 (comment)
Originally created by @frivoal on Fri, 08 Jun 2018 04:40:12 GMT


@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.

@frivoal

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 3, 2018


Migrated from WICG/spatial-navigation#58 (comment)
Originally created by @jihyerish on Fri, 09 Nov 2018 02:28:15 GMT


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

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 4, 2018

I've added a feature policy based mechanism to the spec to control this, based on the discussions we had at TPAC. see 1ad7739 for details.

I've added a privacy and security appendix while I was at it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.