Scope and complexity (was Re: More on XSS mitigation)

On Fri, Jan 21, 2011 at 3:51 PM, Lucas Adamski <lucas@mozilla.com> wrote:
> 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.

It's not the difficulty of implementation that concerns me.  We
certainly have the engineering bandwidth in WebKit to implement CSP.
What worries me is the complexity of using CSP.  Part of trying to
build something simple is that its easier for developers to understand
and use correctly.

To pick on one example, adding "inline" as script-src is disaster for
security, yet its temping enough that a number of folks who've I've
seen try to use CSP decide to add it.  IMHO, CSP would be better at
mitigating XSS without the "inline" option for "script-src".

> 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.

I agree that we should be threat-focused rather than attack-focused.
We seem to agree that the threat we'd like to mitigate is the threat
from an attacker who can inject content (e.g., HTML) into the honest
site, right?

> 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".

Indeed:

---8<---
Whenever the user agent would load a plug-in on behalf of a document,
if the document has an "allowed scripts policy", if the origin of the
URL from which the user agent retrieved the plug-in is not contained
in the allowed scripts policy, instead do not load the plugin and
queue a task to fire a simple event that bubbles named
SecurityViolation at the element that attempted to run the script.
--->8---

More problematic than Flash is Java, actually, because setting
mayscript="false" doesn't actually prevent the Applet from script the
page.  O_o

Adam


> 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.

Received on Monday, 24 January 2011 23:51:46 UTC