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.

Sign up for GitHub

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

Jump to bottom

Prevent programmatic focus in iframe #543

Closed
marian-r opened this issue Jan 25, 2019 · 13 comments
Closed

Prevent programmatic focus in iframe #543

marian-r opened this issue Jan 25, 2019 · 13 comments

Comments

@marian-r
Copy link

I would like to propose a way to restrict iframe from programmatically setting focus on any of its inputs. Restricting would mean that the .focus() calls inside the iframe would have no effect. I am proposing that it could be achieved with a new feature policy or a sandbox flag, not sure which one suits more to this case:

sandbox:
<iframe src="ad.html" sandbox="allow-focus-calls"><iframe>

feature policy:
<iframe src="ad.html" allow="focus-calls"><iframe>

(The name of the flag is just an example. Feel free to propose a better name)

I am a Software Engineer working on advertising security for a house of large online publishers (Yahoo, Tumblr, HuffPost, TechCrunch, AOL to name a few). The reason behind this proposal is that it gives a way for publishers to improve the security of visitors by restricting the ability for (malicious) ads to programmatically steal focus without users noticing.

Example:

<html>
<body>
<h1>Top page</h1>
<iframe src="ad.html"><iframe>
</body>
</html>
<html>
<body>
<p>Iframe</p>
<input id="textInput" type="text">
<script>
document.getElementById('textInput').focus();
</script>
</body>
</html>

The iframe in the example 'steals' focus from the top page as soon as it loads.
@dveditz
Copy link
Member

dveditz commented Jan 28, 2019

This idea seems reasonable to consider. I suspect feature policy is the better fit but I could be convinced otherwise. In any case this top-level issue tracker is a good place for this request to get lost: it's mostly deprecated in favor of spec-specific issue trackers. Of course that means you'll have to decide which spec first.

Sandbox is governed by the HTML spec; CSP simply follows. For that mail the whatwg mailing list or maybe https://github.com/whatwg/html/issues/ . For feature-policy you could try the WICG discourse forums. You could also try to catch a subset of both groups by mailing the public-webappsec@w3.org list

+@annevk what do you think the best next steps would be?

@dveditz
Copy link
Member

dveditz commented Jan 28, 2019

Feature policy issues are tracked at https://github.com/w3c/webappsec-feature-policy/issues

@annevk
Copy link
Member

annevk commented Jan 29, 2019

It sounds like sandbox does not correctly prevent focus stealing. Unless user agents are willing to make that (breaking) change, feature policy might be the way to go. Not entirely sure on next steps, it would be nice if sandbox covered this, so maybe filing a cross-linked issue against whatwg/html and w3c/webappsec-feature-policy is a way forward here.

@marian-r
Copy link
Author

Thanks folks, will try to use all of those channels and let's see what will be the way forward.

@annevk I have a feeling it would be a breaking change regardless of whether it lands in feature policy or sandbox. Or am I missing something?

FYI: Firefox already prevents iframe from stealing the focus when some input element has focus.

This was referenced Jan 29, 2019
Open
Open
@annevk
Copy link
Member

annevk commented Jan 29, 2019

@marian-r I was envisioning it would be allowed by default if we did it through feature policy. If Firefox already has some restrictions around this there might be more wiggle-room though.

@marian-r
Copy link
Author

@annevk to be more precise, Firefox prevents it when these conditions are met:

  • Iframe is cross-domain (which is usually the case in advertising)
  • Some input element has focus, either via autofocus attribute or via user's interaction (click/tab)

And I've just now realized that each feature policy directive has different default value. I thought they are all disabled by default when allow iframe attribute is used. So what you are suggesting, to disable it by default, now makes sense to me 👍

@clelland
Copy link
Contributor

@marian-r, it wouldn't be breaking if we made it controllable through feature policy, with a default allowlist of *; then it would be an option which could be disabled, but would be enabled by default everywhere.

Adding it to sandbox is potentially breaking, as it would immediately affect every sandboxed frame; all sites would need to update their code to avoid it if they needed the cotntrol back.

As a feature policy feature, we could also decide to apply it by default to sandboxed frames, if we later realize that it should be disabled by default in sandboxes; we haven't done anything like that yet, but there's no reason we can't.

@clelland
Copy link
Contributor

(And now I see the comment where you already realized all of that :) )

@marian-r
Copy link
Author

@clelland sounds great. What would be the next steps now?

@Malvoz
Copy link

Malvoz commented Jan 29, 2019

This is closely related to w3c/webappsec-permissions-policy#175, I suspect @frivoal or @jihyerish may have opinions or insights on this.

@marian-r
Copy link
Author

What would be the next steps with this proposal?

@dveditz
Copy link
Member

dveditz commented Feb 18, 2019

Closing in favor of the better-homed w3c/webappsec-permissions-policy#273

@dveditz dveditz closed this as completed Feb 18, 2019
@t3chguy t3chguy mentioned this issue Dec 17, 2019
Open
@uhrohraggy
Copy link

uhrohraggy commented Feb 15, 2020 •
edited
Loading

Thank you guys. I have a legitimate accessibility need for having focus needed in a cross-domain iframe to be allowed with keyboard nav. This thread helped me realize there was the Feature policy directive. thank you guys! https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@clelland @dveditz @annevk @uhrohraggy @marian-r @Malvoz