A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
AllowSeamless: Difference between revisions
(→CORS) |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 21: | Line 21: | ||
==Proposal== | ==Proposal== | ||
One approach is to use an attribute of the <code>html</code> element to indicate that this document is willing to be displayed seamlessly with cross-origin parents. If the <code>html</code> element has an attribute <code>allowseamless</code> and if the document is displayed in an iframe that contains the <code>seamless</code> attribute, then the iframe will resize automatically and attempts to navigate the frame will be redirected to the containing frame: | |||
<html allowseamless> | |||
<body> | |||
If my parent iframe has the seamless attribute, then <a href="http://example.com">this | |||
example link</a> will navigate my parent and the iframe will autosize to the right height | |||
and width. | |||
</body> | |||
This situation differs slightly from how seamless works normally in that styles are not inherited from the parent document to the child. We don't inherit styles by default because inheriting cross-origin styles is significantly more risky than autosizing (see Security Concerns above). If the author wishes the document to inherit styles from its parent, the author can include the token <code>inherit-style</code> in the value of the attribute: | |||
<html allowseamless="inherit-style"> | |||
<body> | |||
Now in addition to the above, I will inherit styles from my parent. Inheriting styles requires | |||
an additional opt-in because letting my parent style me could leak more information (such | |||
as the value of form input elements) to my parent. | |||
</body> | |||
It's likely we should treat the value of the <code>allowseamless</code> attribute as a space-separated list of tokens to allow for future extensions. | |||
==Alternatives== | ==Alternatives== | ||
| Line 36: | Line 56: | ||
In this approach, the server includes a <code>Content-Security-Policy</code> (CSP) HTTP header that includes an <code>allow-seamless</code> directive. Unfortunately, this approach conflicts with the basic premise that CSP directives ''tighten'' the security of the document. In this case, the <code>allow-seamless</code> would ''loosen'' the security of the document and potentially expose it to attacks. | In this approach, the server includes a <code>Content-Security-Policy</code> (CSP) HTTP header that includes an <code>allow-seamless</code> directive. Unfortunately, this approach conflicts with the basic premise that CSP directives ''tighten'' the security of the document. In this case, the <code>allow-seamless</code> would ''loosen'' the security of the document and potentially expose it to attacks. | ||
== | ===Per-Origin Control=== | ||
Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using <code>Frame-Options</code> or <code>ancestor-origins</code> because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame. | |||
===Meta Element=== | |||
Rather than using an attribute on the <code>html</code> element, we could use a <code>meta</code> element. That would work too. The choice is mostly aesthetic. Because seamless already interacts with the document element (e.g., to propagate styles), placing the indicator on the <code>html</code> element seems more aesthetic, but this is a topic upon which reasonable people might disagree. | |||
[[Category:Proposals]] | [[Category:Proposals]] | ||
Latest revision as of 00:15, 27 May 2012
Overview
Currently, seamless iframes work only with same-origin document because otherwise the parent document could steal information from the child document. There are use cases (see below) for using seamless iframes with cross-origin documents. This proposal provides a way for documents to opt into being seamless with cross-origin parents.
Security Concerns
There are two main concerns with allowing seamless to be used across origins:
- Seamless iframes adjust their size automatically based on the content inside the iframe. If the height or width of a document contains sensitive information, that information will be leaked to the parent if the document is displayed seamlessly. For example, a shopping cart page might be taller the more items are in the shopping cart.
- CSS styles inherit across from the parent document to its seamless children. If a malicious parent is able to inject styles into a cross-origin child, the parent could potentially learn sensitive information. For example, the parent could learn whether elements exist in the child document that match various selectors, including attribute value selectors. An attacker might be able to use this technique to extract the values of HTML input elements, for example.
Use Cases
Dashboard
A dashboard web site wishes to display status indicators that are hosted on a number of different domains. The size of these status indicators varies depending on the status. For example, if a given domain is having difficulty, the status indicator might list the problems the domain is having.
Expandable Advertisement
A publisher wishes to display an advertisement that expands when the user interacts with the advertisement. Today, the common practice is for the advertising network to run script in the publisher's page that receives postMessage instructions to resize the advertisement's iframe, but this requires that the publisher allow the advertisement to run script in its page, potentially compromising the publisher's security.
Proposal
One approach is to use an attribute of the html element to indicate that this document is willing to be displayed seamlessly with cross-origin parents. If the html element has an attribute allowseamless and if the document is displayed in an iframe that contains the seamless attribute, then the iframe will resize automatically and attempts to navigate the frame will be redirected to the containing frame:
<html allowseamless> <body> If my parent iframe has the seamless attribute, then <a href="http://example.com">this example link</a> will navigate my parent and the iframe will autosize to the right height and width. </body>
This situation differs slightly from how seamless works normally in that styles are not inherited from the parent document to the child. We don't inherit styles by default because inheriting cross-origin styles is significantly more risky than autosizing (see Security Concerns above). If the author wishes the document to inherit styles from its parent, the author can include the token inherit-style in the value of the attribute:
<html allowseamless="inherit-style"> <body> Now in addition to the above, I will inherit styles from my parent. Inheriting styles requires an additional opt-in because letting my parent style me could leak more information (such as the value of form input elements) to my parent. </body>
It's likely we should treat the value of the allowseamless attribute as a space-separated list of tokens to allow for future extensions.
Alternatives
CORS
In this approach, the server opts into allowing seamless by supplying CORS headers that allow the parent access to the document. This approach has a number of disadvantages:
- In order to opt into autoresizing, the child document must allow the parent full read access to its contents because the parent can use cross-origin
XMLHttpRequestrather than an iframe to retrieve the document. Although autoresizing leaks some amount of information about the child, some servers might want to opt into autoresizing without leaking all the information in the document. - If the document contains subresources, the some information from those subresources might leak to a seamless parent. For example, if the child document contains a seamless iframe to third document from the same origin as itself, information about the height of that third document might leak to the parent. This violates the semantics of CORS, which operates per origin.
- CORS is awkward to use with resources that require cookies because
Access-Control-Allow-Origin: *works only with credential-less requests. If the child uses cookies, the server will need to supply aVary: Originheader, which makes caching difficult (and triggers bugs in some proxies and older versions of IE). For this reason, CORS works better with static resources, such as images and scripts, than with dynamic resources, such as server-generated HTML documents.
Content-Security-Policy
In this approach, the server includes a Content-Security-Policy (CSP) HTTP header that includes an allow-seamless directive. Unfortunately, this approach conflicts with the basic premise that CSP directives tighten the security of the document. In this case, the allow-seamless would loosen the security of the document and potentially expose it to attacks.
Per-Origin Control
Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using Frame-Options or ancestor-origins because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame.
Meta Element
Rather than using an attribute on the html element, we could use a meta element. That would work too. The choice is mostly aesthetic. Because seamless already interacts with the document element (e.g., to propagate styles), placing the indicator on the html element seems more aesthetic, but this is a topic upon which reasonable people might disagree.