allow-same-origin iframe potential issue with signed exchange

[zhouyx]

Based on the paragraph that @cramforce wrote, redirection within allow-same-origin iframe can easily create make the iframe a friendly iframe.

This won't happen for cached AMP pages because the iframe origin can never be the same as the cache origin. However what about the case with signed exchange?

cc @cramforce @Gregable @aghassemi @lannka @torch2424

[aghassemi]

@zhouyx yes, it is a problem. We are tracking a new feature request for Chrome where we "Ensure AMP frames can never mess with their parent (whether or not actually hosted on the same origin)." Some early discussions here: whatwg/html#2757

Essentially unless we can detect a redirect origin change before the page has a chance to interact with parent ( I haven't tried to find a solution but looks unlikely ), this becomes a blocker for web packaging.

To build on @zhouyx's point, allowing same-origin amp-iframe in the current state is technically equivalent to allowing <script async src=whatever> in AMP.

[twifkak]

cc @ampproject/wg-caching

[twifkak]

see also: https://github.com/dtapuska/documentaccess

[twifkak]

Quick note that "iframe origin can never be the same as the cache origin" is not true; redirect can evade that too. But cache prevents that resource from being too much of a problem for the unsigned case.

[dfabulich]

I was thinking about this bug today, and I think a workaround might be possible without adding a new feature to the web platform.

What if the AMP SXG validator required the SXG to have a Content-Security-Policy frame-src explicitly allowing all and only the origins of its <amp-iframe> elements?

That way, a www.example.com SXG could have an <amp-iframe> pointing to iframe.example.com, but that iframe would be forbidden to navigate back to www.example.com and thereby become friendly, because CSP would prevent iframes from www.example.com; it would only allow unfriendly iframes from iframe.example.com.

Would that work?

[cramforce]

I think a problem with such an approach is that it can be extremely difficult to enumerate iframe origins.

In general, AMP would really like to allow same-origin iframes. It also wants to avoid them scripting the parent. Not for security or compliance reasons, but because it would break on the cache in unexpected ways, and AMP aims to avoid documents breaking on the cache in unexpected ways.

That is also why we've so far ignored the "redirect hack" that was always possible for on-origin AMP docs since it wasn't about security, but rather the hosting invariant.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.