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

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

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 25 Jan 2011 15:57:23 -0800
Message-ID: <AANLkTik=YOCvAf3mw6nyj5CqAU2q-aydHbqa1=e+2WFF@mail.gmail.com>
To: Brandon Sterne <bsterne@mozilla.com>
Cc: Gervase Markham <gerv@mozilla.org>, Lucas Adamski <lucas@mozilla.com>, public-web-security@w3.org
On Tue, Jan 25, 2011 at 3:19 PM, Brandon Sterne <bsterne@mozilla.com> wrote:
> On 01/25/2011 02:32 PM, Adam Barth wrote:
>>> Others have expressed interest in the existing CSP features within this
>>> discussion.  If people find the features useful now then why would take
>>> a wait-and-see approach to building them in to the model?
>>
>> Because I'd like to wait-and-see whether they're right.  :)
>>
>> Less glibly, I think that CSP has a bunch of ideas bundled together.
>> I think some of those ideas are great (like limiting where you get
>> scripts from), but I think that others aren't as great (e.g., limiting
>> where you can XHR or the clickjacking mitigation).  I'd like to
>> implement the great ideas now and pave the way for implementing more
>> great ideas in the future.
>
> I do think we're getting somewhere, for what it's worth :-)

That's good.  It seems clear to me that we should be able to figure
something out.

> I agree with you that some of CSP's features are obvious wins. Some of
> the features are less obvious in terms of immediate benefits provided
> (more on that below).  I think we disagree on which features are obvious
> wins.  I would place content restrictions in the category of obvious
> win. We have heard people say that CSP "would be a lot less useful if it
> didn't include those capabilities".  This is not a matter of
> waiting-and-seeing if they are "right". These features fit in to their
> current use cases.
>
> If you have concrete reasons why specific features should be abandoned
> or deferred until later, now is the time to bring them up. Otherwise,
> CSP offers a solution to a real set of problems.  There may be ways to
> improve the solutions and we should adopt those if we can discover them.
>  If not, then CSP surely must be better than no solution.

Rather than lump CSP features into "now" and "later", I'll try to rank
them in order of how impactful they seem to me.  Ideally we'd be able
to arrange things so that we don't have to agree over where to draw
the line between "now" and "later".

script-src
object-src
report-uri
style-src
frame-src
policy-uri
img-src
xhr-src
frame-ancestors
media-src
font-src
options eval-script
options inline-script

In the list above, I'm using CSP syntax, but I mean them to represent
the feature behind the syntax, or what I imagine the syntax to be
useful for.  For example, I'm not in love with the report-uri
mechanism, but in listing it above, I mean the "web sites should be
able to get telemetry data about how well their site complies with
their policy" feature.

There are also some features I think would be valuable that aren't in CSP:

utf8-damn-it
no-outgoing-referrer
object-types <media-type-list>
block-third-party-cookies

I'm not sure exactly where they fit in my priority list, and I'd like
to defer that decision until later, but they're on my radar.

> I've argued that we should provide more levers because we may be faced
> with future threats that can be mitigated by pulling some combination of
> the levers.  Admittedly, this is a difficult position to defend as there
> are no clear and present dangers that all of the proposed levers map to.
>  It would be productive, I think, to debate the merits of the individual
> features rather than saying "script loading is the only useful part; the
> rest should be dismissed".  We already have evidence to the contrary.

I feel like CSP, as currently designed, is locking us into it's 1.0
vision.  If we had something that was more extensible, then we could
add more functionality over time.  Maybe this is a byproduct of
thinking in the web style of "release early and iterate" (e.g., as
espoused by Paul Graham and others), but I'd to start with the minimum
viable feature and build from there.

Adam
Received on Tuesday, 25 January 2011 23:58:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 January 2011 23:58:31 GMT