[filter-effects-1] Document Clickjacking Attacks

[arichiv]

This formalizes the proposal here: https://chromestatus.com/feature/5117170452398080

[arichiv]

Chrome is currently discussing whether all iframes, or just iframes that are cross-origin with their parent, should have the SVG filter un-applied. Soliciting feedback on that here.

[rebane2001]

From a security perspective, same-origin frames allowing filters would be on-par with how the rest of the restrictions with frames work. The concerns would probably be additional complexity in the case of nested frames, and confusing behavior where filters work on one frame but not another. I personally like the idea of still being able to use filters on my own frames :).

[tabatkins]

Yeah, there's no good reason to disallow filters on same-origin iframes. A same-origin iframe is not remotely a security boundary.

[Psychpsyo]

What exactly does this mean?
If I set an SVG reference filter somewhere further up on the tree, so that it applies to some area of the page and the cross-origin frame within, does the filter as a whole become invalid? Or is it expected to leave only the iframe alone somehow and still apply to the content around it?

[arichiv]

I think it's up to the user agent, though @progers may disagree. Assuming a setup like:

<div class="svg-filter">
  [...stuff...]
  <iframe src="remote origin"></iframe>
</div>

Ideally the 'stuff' still has the filter applied while the iframe does not, but if the design of the painter for the user agent precludes this somehow, it's better to fully invalidate the filter on all content than apply it to the iframe.

[Psychpsyo]

I think the spec should at least be explicit with regards to the fact that this should apply to all reference filters that would/could end up using pixel data from the iframe. Otherwise, to a particularily lazy implementer, the interpretation of "only filters applied to the iframe directly" is on the table, which ends up negating all the intended security gains. Similarily, one might naively expect this to mean "all filters up the iframe's hierarchy", which is problematic as well, because of backdrop-filter.

I also worry that, if the details of this are left unspecified, it will lead to other browsers ultimately having to reverse-engineer Chrome once they get bug reports along the lines of "This backdrop filter on my modal isn't applying at all, but it works in Chrome."

Then again, I just tried that and Chrome 151 will still happily apply these filters to an iframe if done via backdrop-filter on an abspos element in front of the frame. So maybe it wouldn't be the worst idea for the spec to give some guidance here. WebKit and Gecko seem to get around this by just not applying the filter at all in that case. (In the regular filter case, they both manage to exempt only the iframe and not the rest of the page. Although in Gecko, the iframe does turn solid white.)