W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Re: Seamless iframes + CSS3 selectors = bad idea

From: <sird@rckc.at>
Date: Tue, 8 Dec 2009 18:24:12 +0800
Message-ID: <8ba534860912080224i188c94a9kaa29e5af569bbd7@mail.gmail.com>
To: gaz Heyes <gazheyes@gmail.com>
Cc: Adam Barth <w3c@adambarth.com>, Daniel Glazman <daniel@glazman.org>, Thomas Roessler <tlr@w3.org>, public-web-security@w3.org
In my opinion there are NOT millions of websites using these selectors, and
even if they were, maybe that's the price that has to be paid in this case..

I want to demonstrate the case of Microsoft and CSS expressions. They ARE
used by millions of websites (even google uses them), and affect MILLIONS of
users.. but that didn't stopped microsoft from dropping it's support due to
security concerns.

This was a great decisions by microsoft (to put the security of it's IE
users over what the developers want).

As said in the begining of this thread... sometimes the safest way to do
something is NOT to do it.

-- Eduardo

Sent from Hangzhou, 33, China

On Tue, Dec 8, 2009 at 6:01 PM, gaz Heyes <gazheyes@gmail.com> wrote:

> 2009/12/8 Adam Barth <w3c@adambarth.com>
>> Also, what about confidential
>> information written in the page, like account numbers or social
>> security numbers?  I don't see why all the secrets must necessarily be
>> stored in value attributes of input elements.
> Yeah account numbers would be very easy to get and require less rules. Any
> data that is realistically bruteforced with CSS rules is a target. But the
> *= selector is quite dangerous because you can do a word search of values.
> Me and Sirdarckcat were discussing using the start/end selectors to acquire
> an email address for example. It isn't as difficult as it first seems, you
> match the TLDs at the end $=.com then use a dictionary attack on the value
> before the @ so ^="foo@" ^="bar@" etc then use the *= selector to find the
> letters of the domain and find the anagram.
> Also you could steal tokens by checking for overlapping values, so you know
> the start and end, you know which characters the token doesn't contain, you
> know the three character patterns it does contain. You could then jigsaw the
> pieces together to form the token.
Received on Tuesday, 8 December 2009 10:25:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:23 UTC