- From: Dan Veditz <dveditz@mozilla.com>
- Date: Fri, 02 Nov 2012 12:25:35 +0100
- To: "L. David Baron" <dbaron@dbaron.org>
- CC: Adam Barth <w3c@adambarth.com>, Ian Melven <imelven@mozilla.com>, public-webappsec@w3.org, Jonas Sicking <jonas@sicking.cc>
On 11/2/12 11:01 AM, L. David Baron wrote: > On Monday 2012-10-22 15:28 -0700, Adam Barth wrote: >> The main threat we're trying to protect against is attackers who can >> inject markup into a document using CSS3 attribute selectors to steal >> passwords (and other data) store in input element attributes. Also, >> we're worried about future evolution of CSS increasing this risk. > > When are passwords and other data typically stored in input element > attributes? When users edit the value in a form control, the change > to the current value of the control does not change values of > attributes, which represent the default value. So the only thing > attribute selectors can select on is the default value, not the > current value. (The exception to this is <details>.) The main concern is the "and other data", in particular anti-CSRF token values which are often present in hidden fields. > Also, if issues with selectors are the security risk that you're > trying to address, it's not clear to me why you need to block style > attributes at all (unless you're expecting the proposal to support > selectors in the style attribute to be implemented sometime). That would be somewhat worrying if there's a chance it'll happen. I think the main concern was injected page content trying to overlay the existing content, perhaps performing a phishing or clickjacking type attack. Of course if the injection is early enough in the page you can displace the existing content without having to overlay it. -Dan Veditz
Received on Friday, 2 November 2012 11:26:06 UTC