W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: More on XSS mitigation (was Re: XSS mitigation in browsers)

From: Lucas Adamski <lucas@mozilla.com>
Date: Fri, 21 Jan 2011 15:51:16 -0800
Message-Id: <9C335E35-C6DA-4C46-B36B-6345891205AB@mozilla.com>
To: public-web-security@w3.org
True, but in the time we have spent debating the complexity of this feature, we at Mozilla have managed to implement essentially the whole thing with just 2 developers working part time.  The complexity to implement the feature should always be evaluated against the benefit it provides.  Browsers have a huge force multiplication factor; if a line of code we write can save many thousands of developers writing many complex and hard to maintain lines of code, its worth it.  Occams razor states that out of all equally good solutions, the simplest is generally best.  Simplicity cannot be the paramount criteria for evaluating proposals.  In addition, part of the goal of this group I believe is to work towards a unified policy delivery mechanism.  Which doesn't imply the strawman of solving all problems before moving forward, as true uniformity requires extensibility. 

There's a fundamental question about whether we should be looking at these problems from an attack vs threat standpoint.  An attack is XSS.  A threat is that an attacker could compromise a site via content injection to trick the user to disclosing confidential information (by injecting a plugin or CSS to steal data or fool the user into sending their password to the attacker's site).  We've certainly seen some interesting CSS attacks lately, resulting in CSRF attacks equivalent to the damage potential of XSS.

Regarding the merits of your specific proposal, you would need to also control plugin embedding at absolute minimum to mitigate code injection in any meaningful way, otherwise I just inject a Flash movie with "allowScriptAccess = always".  Regards,

On Jan 21, 2011, at 2:20 PM, Adam Barth wrote:
> Security is a multi-faceted topic that we're unlikely to solve all at
> once.  One approach that might work well is to have in mind a broader
> vision of where this security mechanism can go, but to make progress
> one step at a time.  This general approach has worked well for HTML,
> for example.  The first version of HTML didn't have every conceivable
> feature under the sun.  It started small and over time grew to be able
> to handle more and more use cases.
> Adam
Received on Monday, 24 January 2011 17:59:48 UTC

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