W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] some thoughts on sandboxed IFRAMEs

From: Philip Taylor <excors+whatwg@gmail.com>
Date: Fri, 5 Feb 2010 14:51:42 +0000
Message-ID: <ea09c0d11002050651n2129fd01n5f414866bfb3782c@mail.gmail.com>
On Thu, Feb 4, 2010 at 11:12 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 25 Jan 2010, Alex Russell wrote:
>>
>> AFAICT, the objections fall into several buckets:
>>
>> ? 1.) Users might pick badly or may re-use nonces when they shouldn't.
>> ? 2.) Escaping " is believed to be more secure because it's likely to
>> break more often, raising developer awareness
>> ? 3.) The fix to correct escaping problems is believed to be more reliable
>>
>> I'm interested in 2 and 3. Users will do dumb things, and both 2 and 3
>> assumes a similar baseline scenario as 1; a developer did something
>> dumb. Nonces need not be cryptographically strong for most apps, so
>> the big problem is re-use. UA's have broad leeway here to prevent
>> re-use on origins and deny sandboxing to containers that re-use the
>> same nonces on a single page. They can even help by keeping a list of
>> recently used nonces and denying reuse.
>
> Could you elaborate on how one could avoid reuse? That seems like a bad
> idea, since it would prevent any non-client caching mechanism from
> working. The problem is not nonce re-use, it's that the token has to be
> either unpredictable or unspoofable. (It could be predictable and
> unspoofable if it was constructed using a diagonal of the user's text.)

Seems like it should be easy to get secure tokens by doing:

  $token = sha512_hex($input);
  print "<sandbox token=$token>$input</sandbox token=$token>";

(or whatever the sandbox syntax is), so there's no need to worry about
cryptographically secure RNGs or nonces or reuse or caching problems.
Is this what you meant by "a diagonal of the user's text"?

(I'm assuming here that the UA treats the token as an opaque blob, it
doesn't try to recompute the hash itself, so it's robust to changes in
character encoding etc. People could still choose insecure tokens
instead, but it's pretty trivial to use the hash solution correctly in
most programming environments (easier than good random numbers). To
attack it, you'd have to pick two strings X and Y and a hash H such
that hash(X+"</sandbox token="+H+">"+Y) = H, which for a good hash
function should be hard, I think.)

-- 
Philip Taylor
excors at gmail.com
Received on Friday, 5 February 2010 06:51:42 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC