W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2012

Re: CSP and cross-frame communication

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 29 Feb 2012 14:04:30 -0800
Message-ID: <CAJE5ia83z2v2qj12oi0u81z1PHZneiE9Lnjz14XrGA-SOmTnDQ@mail.gmail.com>
To: David Bruant <bruant.d@gmail.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I'm sorry, but the platform cannot current support your use case.
There are only two levels of trust in the platform: either you trust a
document or you don't.  If you trust the document, then it can do
anything that you can do.  If you don't trust it, then you're fully
isolated from it and can communicate with it using postMessage, etc.

Adam


On Wed, Feb 29, 2012 at 1:53 PM, David Bruant <bruant.d@gmail.com> wrote:
> Hi,
>
> Before answering to your message, I'd like to provide a more practical
> use case. I've written up a little demo [1].
> My case is as follow:
> I have a "main.html" page opening a "compromised.html" iframe. It is a
> same-origin iframe. I want this iframe to do useful stuffs ("useful
> code" not included in the example), so there is no reason to restrict
> what it has access to (built-in forms, scripts, local storage), no need
> to sandbox it. I do trust it. (This is not an irrealistic use case.
> Right now, on my Facebook page, there are 2 not sandboxed iframes.)
> Among the useful stuff that could be considered for the iframe could be
> delegating local storage related things to the iframe.
>
> But, as its name suggests, for some reason, this iframe (only) gets
> compromised and malicious code can run in it. Thanks to the same-origin
> policy, the attacker now has access to the top level page and especially
> the DOM. In my example, the attacker creates a button on the main page.
> (To make things worse, I thought that the iframe could even manipulate
> the history API, but it didn't work for me on Firefox)
>
> Potential solutions:
> 1) sandbox the iframe
> => If so, then, I may not be able to achieve what I needed to be done in
> the normal (not compromised) case.
>
> 2) load my main page with the sandbox directive
> => the main page cannot use the local storage
>
> My idea is to have something less restrictive than the sandbox directive
> as currently considered. A directive that just prevents any other frame
> to access directly to my environment (including the DOM).
> In the example case, I would just need to add the directive and no
> matter how the iframe is compromised, it won't be able to climb up to
> reach my DOM.
>
> Le 28/02/2012 00:52, Daniel Veditz a écrit :
>> On 2/25/12 12:44 PM, David Bruant wrote:
>>> I think that this is annoying. I understand the necessity of isolating
>>> the scripts running in a frame from scripts running in other frames, but
>>> I don't see why this would be done at the cost of features (especially
>>> local storage which has no replacement)
>> Either you trust those scripts or you don't.
> Things are not always black and white. Sometimes, you trust an
> advertiser enough to show an ad on your website, but not enough to mess
> with the rest of your website. That's how the Adsafe [2] project started.
>
> Your point also forgets the temporal dimension. At some point in time,
> you can know you trust or don't trust. But what if you trust and later
> your iframe gets compromised like as I have showed above?
>
>> If you don't they might
>> be stealing confidential data from localstorage or they might be
>> injecting data that leads to DOMXSS or other security bugs.The best
>> we could do safely is allow sandboxed content to access an anonymous
>> temporary form of storage.
> With the directive I'm proposing, the worst thing an attacker can do is
> messing with the iframe and steal data from the local storage, which, I
> think is far better than having control over the main page.
>
>> If you trust the content then don't sandbox; if you distrust it then
>> sandbox and you'll have to set up a postMessage() gateway to pass
>> sanitized information back and forth.
> I trust, but don't need more than postMessage to achieve what I need.
> I'd like to restrict cross-frame communication to this. In a way,
> consider any iframe like a worker to which I may have attributed a part
> of the screen.
> Are there forms of cross-frame interactions that cannot be achieved with
> postMessage? There might be an issue of performance and cross-browser
> support (until IE6-7 die), but functionnally, same-origin synchronous
> access does not seem necessary to build applications.
>
> David
>
> [1] http://davidbruant.github.com/Iframe-attack/main.html
> [2] http://www.adsafe.org/
>
Received on Wednesday, 29 February 2012 22:05:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 February 2012 22:05:31 GMT