I'm not sure what the security issue is here. When you say "protection screen" divs, is this an anti-clickjacking technique, or anti-fraud?

In general, this sounds like a functional bug affecting website behavior, as the behavior in Chrome dates back to at least M-60 per  Issue 864849   #4  (which would about a year ago on Stable), rather than a vulnerability in Chrome.

Could you clarify the concern more or provide a basic reproduction case?

molnarg@: How do embeddable widgets distinguish between benign vs malicious embedders? I can imagine some kind of postMessage exchange to establish trust, but it's hard to think of something that is broadly practical and couldn't be spoofed.

i.e. It would be easier to whitelist valid embedders via CSP headers.

I'm just trying to understand whether this has a security impact in practice.

It's more of anti-fraud technique.

Consider this generic frame-busting method, that has optimal rendering performance, thanks to the asynchronous embedder check (and the transparent protection screen overlay that enables it) and being cache friendly.
1. The widget is a static, cache-able HTML, that has no header that prevents it from being embedded
2. The widget code starts loading the content and rendering the page once loaded independently of the embedder
3. There is a transparent overlay on top that prevents clicking anywhere in the widget until the overlay is removed
4. As soon as possible, start a postMessage based handshake with the embedder, so that the widget gets to know the origin of the embedder
5. Issue an XHR to the widget's server with the embedder origin as payload, that let's the server check the embedder (based on white/blacklist)
5. If the server response is 'allow', then the transparent overlay is removed, and clicking is enabled
6. If the server response is 'deny' then stop loading and delete the page's content

This way, the rendering of the widget starts as soon as possible, since there's no need to wait for the result of the check, it happens asynchronously. There are no headers that would prevent caching, or server side processing in the critical path that would slow down the initial HTML response.

I can't cite examples that use this pattern, as anti-fraud techniques are usually not public. But based on that this is the optimal performance solution for embeddable widgets, I suspect that it is used.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I see, and I guess the advantage of that over whitelisting via CSP frame-src directives is that you get a dynamic list of legal embedders that don't have to be present in headers.

It sounds like  issue 864849  is only a problem if the transparent overlay is in a different frame than the vulnerable HTML though, right? If the overlay and the served content were in the same frame then mistargeting frames would be irrelevant. I suspect they actually are in different frames though, and this is a nested iframe scenario.

cthomp@: This sounds like it would be reasonable to flag the problem as Severity-Low. Usually we would flag and RestrictView the original bug though, because it is awkward to have two bugs having the same problem, with one having security flags and the other not.

+mbarbella, -cthomp, reflecting security sheriff change-over. 

Do we think the fix for  Issue 864849  (which landed ~1 hour ago) is sufficient for the security concerns?

(Adding some labels per suggestion of #5.)

It sounds like it, yes. The problem was just that touches were occasionally getting targeted to the wrong frame.

Marking this as fixed then. As this seems low severity, we likely wouldn't merge it back.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot