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  

Received on Tuesday, 8 December 2009 15:17:54 UTC

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