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) |
|||
| Line 33: | Line 33: | ||
===Content-Security-Policy=== | ===Content-Security-Policy=== | ||
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. | |||
==Security Analysis== | ==Security Analysis== | ||
Revision as of 02:07, 24 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
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.
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>