search

WICG / portals

A proposal for enabling seamless navigations between sites or pages
https://wicg.github.io/portals/
Other
946 stars 66 forks source link

Click/input jacking and treatment of X-Frame-Options/CSP frame-ancestors #22

Open dvoytenko opened 6 years ago

dvoytenko commented 6 years ago

The question is whether the portal itself will be considered a top-level context. I.e. will the X-Frame-Options/CSP frame-ancestors observed? I think the area of click/input-jacking deserves an explicit and early planning/analysis.

lucasgadani commented 6 years ago

This is similar to issue #17, but yes, we should support XFO/CSP, since portals have some of the same concerns as iframes when it comes to embedded content.

That said, at least initially we aren't supporting input, so we haven't given clickjacking a lot of consideration.

dvoytenko commented 6 years ago

The actual support of input is not necessary - what we need to consider is a vector where an attacker would overlay the embedded portal and try to steal clicks from it and present the wrong content instead. This is obviously a very common problem, but worth mentioning in this design since portals may have some unique angles.

KenjiBaheux commented 6 years ago

Not for the short term roadmap but +1 to dvoytenko, maybe it's naive of me but I'm wondering if there are simplifications / constraints we could have in Portals that make clickjacking a non-concern, or far easier to reason about.

ithinkihaveacat commented 6 years ago

This is lightly discussed in #17, but I want to emphasize that solving the security concerns around embedding is probably not sufficient: publishers also need a way to avoid situations where their content is surrounded by content (ads?) from other sites without their consent. (So perhaps an explicit opt-in to portals?)

For some examples of user and publisher dissatisfaction with embedding see this 2009 article about the DiggBar or this 2012 article about StumbleUpon, or the multiple questions on StackOverflow about frame busting code, how to prevent websites from putting my site into iframes, etc.

dvoytenko commented 6 years ago

I agree, this has to be an opt-in mechanism.

ghost commented 5 years ago

There are limitations with providing only content which opts-in to embedding. A search engine may wish to use portals for example. Another example might be an intranet site. As the click-jacking issue is a real concern it might be sensible to request permission from the user (in a similar way to location) to ‘Allow web content’? That way a user knows the hosting site is attempting to load third party content. I’d also suggest interaction events over an embedded portal should be hidden from the hosting page. Something similar to “pointer-events: none;”

jeremyroman commented 5 years ago

Requiring a permission popup sounds like it'll make this extremely unattractive to use, because frames don't do it, and because I suspect that unlike things like the camera, the user probably doesn't have the context to evaluate "is it okay to load another document into this browsing context over here"?

dvoytenko commented 5 years ago

I also agree that permissions is going to be a too big of a lift. One approach that could be taken. Portal page would support CSP frame-ancestors. If specified - the portal will function like an iframe. If not specified (or a special CSP header is specified), the portal could still be embedded, but w/o access to cookies. Once activated, the portal page will, of course, get access to cookies per normal. This would be somewhat similar to the document.requestStorageAccess() API, so not completely unprecedented.

ghost commented 5 years ago

From the example Google Search gave for portal use, I understand a blocking user permission would inhibit user flow so agree that may not be a suitable approach. I do believe embedding of third party content needs to be thoroughly considered. Unspecified CSP frame-ancestors headers with blocked cookie and potentially limited/blocked local storage access might allow the implementation to be usable if third party embeddable web content is added to the HTML spec in future.

jakearchibald commented 4 years ago

It would be good to agree on something like X-Portal-Options.

X-Portal-Options would override anything in X-Frame-Options. As in, if X-Portal-Options is absent, X-Frame-Options is used.

jeremyroman commented 4 years ago

The obvious alternative would be to integrate with the more modern CSP instead, or at least imitate it. That might looks something like:

I suspect the general idea here makes sense, but there are details to iron out. Especially if we think we'll ultimately want other kinds of constraints, like "I can be embedded as a portal, but please don't send me input" or "I can be pre-rendered, but I contain sensitive information so don't embed my rendering". I'm not sure whether we do.