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

Re: Seamless iframes + CSS3 selectors = bad idea

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 08 Dec 2009 07:17:18 -0800
Cc: gaz Heyes <gazheyes@gmail.com>, Daniel Glazman <daniel@glazman.org>, Thomas Roessler <tlr@w3.org>, public-web-security@w3.org
Message-id: <37D2043E-FC04-4D55-A3F2-DE6C1A2770BA@apple.com>
To: Adam Barth <w3c@adambarth.com>

On Dec 8, 2009, at 1:38 AM, Adam Barth wrote:

> On Tue, Dec 8, 2009 at 1:35 AM, gaz Heyes <gazheyes@gmail.com> wrote:
>> 2009/12/8 Adam Barth <w3c@adambarth.com>
>>>
>>> That seems to address the proximate issue, but it feel like
>>> blacklisting.  Are there other related attacks we're not thinking of
>>> that would make sense to address at the same time?
>>
>> Well my POC used a dictionary attack to get the value of the first  
>> name text
>> field. There could be information disclosure issues in future.  
>> These could
>> be mitigated by limiting the amount of external requests.
>
> I doubt that limiting the external requests is a viable approach.  I'm
> not aware of any success stories about preventing exfiltration in the
> web platform.  The platform just has way too many ways to send data.
>
> As for other variation, how do these selectors interact with
> contentEditable, for example?  Also, what about confidential
> information written in the page, like account numbers or social
> security numbers?

Both of these would store any interesting information as text nodes  
inside the element. I don't believe any current selectors let you  
select based on text contents of the element.

>  I don't see why all the secrets must necessarily be
> stored in value attributes of input elements.

That is true, but we face a tradeoff between reducing attack surface  
and completely neutering a useful feature. The value attributes of  
input elements are both highly likely to contain sensitive  
information, and are unlikely to be genuinely useful to access via  
selectors.

Regards,
Maciej
Received on Tuesday, 8 December 2009 15:17:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:01 GMT