Re: Seamless iframes + CSS3 selectors = bad idea

Hi!

Yeah.. seamless iframes just enhance the scope of the attack to the whole
origin (instead of the current page).

I tried to persued giorgio maone to lock this selectors on NoScript, but
that had a performance loss that wasn't really afordable (I think that was
the reason.. giorgio can clarify this).

In any case... as I said before, this CSS3 selectors "new toy" is awesome,
I've used it already to:

a[href$=.pdf]::before{content:url(pdficon.gif)}

And it rocks, it really rocks.. but do we really want to give soooo much
power to CSS?

I mean, imho, :visited selectors should have been vanished from CSS3.. but
well..

I think there should be some security guy in the team (if it exists) that
reviews the specs with the power to block features "early" (eg. before
people implement them).. as I see the spec is just a whole bunch of new
features with un-documented new attack scenarios.. quoting gareth heyes..
"if you can think on anything that would make html better for hacking, it
has been implemented on HTML 5".
. (come on.. attributes on closing tags? autofocus? wtf!)

Anyway..

Greetings!!
-- Eduardo
http://www.sirdarckcat.net/

Sent from Hangzhou, 33, China

On Sun, Dec 6, 2009 at 3:34 PM, Adam Barth <w3c@adambarth.com> wrote:

> I think you're missing the main attack that sird's worried about:
>
> Assumptions:
>
> 1) The attacker can injection content into the target web site, but
> cannot injection script.
> 2) The target site uses secret tokens in hidden input fields as its
> CSRF defense.
>
> Consequences:
>
> A) The attacker can mount a CSRF attack against the target web site.
>
> This is bad, but has nothing to do with seamless and everything to do
> with these CSS3 selectors.
>
> Adam
>
>
> On Sat, Dec 5, 2009 at 11:12 PM, Ian Hickson <ian@hixie.ch> wrote:
> > 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.   `._.-(,_..'--(,_..'`-.;.'
> >
> >
>