W3C home > Mailing lists > Public > public-web-security@w3.org > November 2011

Understanding the security model for the sandbox directive

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 4 Nov 2011 00:39:25 -0700
Message-ID: <CAJE5ia9nchqLBVYrGx=d9RJkkFd9j5kOENhvfWFZUK70e3Mxmg@mail.gmail.com>
To: public-web-security@w3.org
Cc: Jacob Rossi <jrossi@microsoft.com>
At TPAC, we discussed whether to include the sandbox directive in CSP
1.0 (i.e., http://www.w3.org/2011/webappsec/track/issues/6).  I've
been thinking through the specification and the implementation, and
I've found that I don't fully understand the security model.

Let's start with some assumptions:

1) You can use the sandbox directive to supply the same sorts of
security policies that you can supply in HTML5's sandbox attribute on
the iframe.
2) The policy supplied in using the CSP sandbox directive affects the
current document only (e.g., it doesn't alter the frame containing the
document in such a way as to cause other documents that might later be
contained in the frame to be sandboxed).

Notice that (2) is quite different from how the sandbox attribute on
iframe works.  In the iframe case, the attribute affects all the
documents loaded in the frame.

Now, I understand the use case of wanting to use the CSP sandbox
directive to move the document into a unique origin.  That works
great.  I'm less clear about the use cases for the other sandbox
tokes.

Consider, for example, the allow-script token.  Omitting the
allow-script token doesn't actually prevent an attacker who controls
the content of the sandboxed page from executing script.  For example,
the attacker can provide a <meta refresh> element that navigates the
frame to an HTML page on the attacker's web site (which lacks a CSP
header).  Because the CSP sandbox directive applies only to the
original document, this second document is free to execute script.
Notice that the same issue doesn't occur with the sandbox attribute on
iframe because the page loaded by the <meta refresh> will also be
contained in the iframe and therefore will have the sandbox policy
applied to it.

Many of the other tokens can by bypassed in similar ways.

Have I misunderstood something about how you intend the sandbox
directive to work?

Assuming the forgoing is correct, there seem to be a couple paths forward:

1) Make the sandbox directive apply to the current document and all
future documents occupying the same frame.  This seems likely to lead
to a bad user experience because the main frame is "poisoned" with the
sandbox policy and will break.

2) Refuse to load documents with a CSP sandbox directive in the main
frame.  Site can, of course, continue to load them in subframes.  We
could then apply the sandbox policy to the iframe and all future
documents that load in that frame.  There's no "poisoning" issues as
above because navigating the main frame clears out the policy.

3) Rather than supporting all the HTML5 sandbox tokens, we could
support only unique origins.  That would have the benefit of a strong
use case and a solid security model, but it wouldn't complement the
sandbox attribute on iframes quite as well.

Of these choices, I favor (2) because I think the main use case for
this feature is for documents intended to be loaded in subframes
rather than documents loaded in the main frame.

Thoughts?
Adam
Received on Friday, 4 November 2011 07:40:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 4 November 2011 07:40:35 GMT