- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 6 Dec 2009 07:12:30 +0000 (UTC)
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: sird@rckc.at, public-web-security@w3.org
On Sat, 5 Dec 2009, Maciej Stachowiak wrote: > On Dec 5, 2009, at 10:27 PM, Maciej Stachowiak wrote: > > > > I think the attack is that you can inject CSS in an unwilling victim > > page by embedding it in a seamless iframe (since CSS rules are > > supposed to cascade into the iframe's contained document per HTML5). > > However, since the contents of a seamless iframe have to be > > same-origin, the embedding page could just script it directly. Thus, > > I'm not sure what the vulnerability is. It's not safe to put a page on > > a given origin that contains data which must not be leaked to other > > pages on that origin. If anyone does that, then violating their > > mistaken assumption is not XSS. It does seem slightly novel that one > > page in a given origin could extract data from another on that same > > origin even if JavaScript is disabled. > > OK, I thought of a possible real vulnerability. A trusted host page on > the site wants to embed some untrusted user-generated content with the > ability to modify it, so it embeds it, hosted from its own server, using > <iframe sandbox="allow-same-origin">. This should prevent scripting and > plugins, so in theory it seems safe. But the untrusted content could > embed a further iframe with the seamless flag, embedding an arbitrary > document from the hosting service. It can then use CSS selectors to > probe for data in that document. Fair enough. I've made the spec make seamless not work inside sandboxed iframes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 6 December 2009 07:13:00 UTC