AllowSeamless: Difference between revisions
|Line 41:||Line 41:|
Revision as of 23:59, 26 May 2012
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.
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.
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.
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.
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
Vary: 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.
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.
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
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.