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
Make recommendations around local-schemed frames. #2
Comments
I'm not sure if we want to communicate this way. COI context only makes attack easier, and normal context can still attack. Also, it'll be also interesting to take telemetry of those frames, and look for process isolation. |
"somewhat mitigated" seems accurate, as there's a substantial reduction in attack bandwidth when shifting from COI environments to non-COI environments.
I'm not sure what this would tell us? The numbers will be 0 in Firefox, for example. Does that substantially change the recommendations we'd want to make here? |
I think when we say “mitigated”, it provides impression to developers that normal context is safe. Reduction in attack bandwidth sounds better.
Yeah, probably it’s off-topic in this discussion :) |
After reading whole document, it's clear that the threat model outlined does indicates the following, which means any cross-site iframe can read content of parent. So maybe this point doesn't need to be added?
|
To close this out, I added a note to https://w3c.github.io/webappsec-post-spectre-webdev/#local-scheme-frames. |
On tonight's WebAppSec call, @shhnjk noted that we should specifically address
<iframe src="data:...">
and<iframe srcdoc {sandbox}>
, as both can create frames which contain dangerous content which could attack its parent. And he's right! We should!We should also note that this risk is somewhat mitigated (or, at least, bandwidth-limited) by the requirement that COI be explicitly delegated to the frame via
allow="cross-origin-isolated"
.@shhnjk: Does this capture your concern?
The text was updated successfully, but these errors were encountered: