W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: [whatwg] some thoughts on sandboxed IFRAMEs

From: Kornel Lesinski <kornel@geekhood.net>
Date: Mon, 25 Jan 2010 23:03:27 -0000
To: "Michal Zalewski" <lcamtuf@coredump.cx>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.u632b10zptj49s@aimac.local>
On Mon, 25 Jan 2010 19:51:33 -0000, Michal Zalewski <lcamtuf@coredump.cx>  

> If you have the intent to display user-controlled input, you have three  
> options:
> <span>[server-sanitized string]</span>
> <iframe srcdoc="[server-escaped string]"></iframe>
> <span guard=[token]>[any string]</span guard=[token]>
> The first two options will not immediately fail if you forget about or
> mess up escaping or sanitization - and people to, all the time. The
> last option just works, unless you purposefully sabotage your code by
> using "1234", or can't generate a random number / session token on
> server side (in which case, you are hosed already - session cookies
> can be guessed, too). The last option strikes me as a bit less
> error-prone.

Not quite. In PHP (and many other web frameworks) sessions tokens are  
generated automatically, so bad programmers may get secure sessions, but  
generate insecure guard tokens. I'm afraid that some authors will simply  
hardcode "random" token in their templates (as in http://xkcd.com/221/ :)

Also, <span guard> has no safe backwards-compatibility at all. Isn't that  
a deal-breaker?

regards, Kornel LesiƄski
Received on Monday, 25 January 2010 23:04:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC