- From: Adam Barth <whatwg@adambarth.com>
- Date: Sun, 13 Dec 2009 12:13:27 -0800
On Sun, Dec 13, 2009 at 11:02 AM, Michal Zalewski <lcamtuf at coredump.cx> wrote: >>?More importantly, though, it puts a significant burden on authors to >> generate unpredictable tokens. ?Is this difficult? ?No, of course not. >> But people *will* do it badly, copypasting a single token in all >> their <iframe>s or similar. > > People already ?need to do this well for XSRF defenses to work, and > I'd wager it's a much simpler and better-defined problem than > real-world HTML parsing and escaping could realistically be. It is > also very easy to delegate this task to existing functions in common > web frameworks. > > Also, a single token on a returned page, as long as it's unpredictable > across user sessions, should not be a significant issue. People screw up CSRF tokens all the time. The closing tag nonce design has been floating around for years. The earliest variant I could find is Brendan's <jail> tag. The @sandbox seems like a better fit for the advertising use case. In fact, many people have told me how happy they are that WebKit is implementing @sandbox. These folks tend to already be using iframes to contain ads or gadgets and wish that they could turn off more features, like frame-busting and plugins. They're not worried about the sandboxed content being loaded in the main frame because they're interested in limiting the attacker's introduction to the user. Once the user has visited attacker.com, the issue is out of their hands. I agree that we need something to help with content received by cross-site XMLHttpRequest and postMessage. For those use cases, we're already running script, so a design like toStaticHTML seems better than <jail>. Adam
Received on Sunday, 13 December 2009 12:13:27 UTC