Re: CSP and cross-frame communication

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 21:54:17 UTC