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

From WHATWG Wiki
Jump to navigation Jump to search
Line 41: Line 41:


==Security Analysis==
==Security Analysis==
==Examples==
<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>
<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>




[[Category:Proposals]]
[[Category:Proposals]]

Revision as of 23:59, 26 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:

  1. 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.
  2. 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

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:

  1. 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 XMLHttpRequest rather 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.
  2. 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.
  3. 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 a Vary: Origin header, 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.

Security Analysis