- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 08 Dec 2009 07:17:18 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: gaz Heyes <gazheyes@gmail.com>, Daniel Glazman <daniel@glazman.org>, Thomas Roessler <tlr@w3.org>, public-web-security@w3.org
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 UTC