Strawman CSP counter proposal

[Adam Barth]

Instead of arguing abstractly about design, I've written up a
(mostly!) complete spec for an alternative CSP design:

https://wiki.mozilla.org/Security/CSP/Strawman

I've purposely gone overboard on the directives, but most of these
directives are based on real feature requests I've received from web
developers. I don't actually think we should do all of them in the
first iteration. I just wanted to give you a flavor of the kinds of
things you could do with this sort of mechanism.

Adam

[Adam Barth]

Based on feedback on another list, I added some directives to the
strawman. I've also divided the directives into maturity levels
(Required / Recommended / Proposed / Experimental).

Adam

[Brandon Sterne]

People generally agree that "content restrictions" are a good idea and
will be a useful tool for websites. Various designs have emerged with
different approaches as to how restrictions should be defined by sites
and applied by browsers. I would like to propose a framework with which
to evaluate and compare the designs to help guide us to a common solution.

The following can be used to determine the costs and benefits of any
particular model for content restrictions:

1. How flexible is the model? How many different use cases does the
model support? Does the model allow sites to keep their baseline
functionality intact?

2. How easy is the model to implement for web sites? How much
specialized knowledge is required by admins?

3. What will the process of developing an appropriate policy look like
for a given model?

4. How easy does the model make it for an organization to reason about
the correctness or optimality of their policy?

5. How will the model fit into organizations' existing workflows? For
example, how easily will organizations who currently perform positive or
negative testing incorporate the model?

6. How extensible is the model? How will the model handle future changes
such as the addition of a new directive, changes in the semantics of an
existing directive (e.g. script-src now restricts plugins'
scriptability), or a change in default behavior (inline style now
blocked by default)?

Please feel free to add any additional criteria that seem appropriate.

Cheers,
Brandon

[Devdatta]

I think 6 should talk about how the model will handle changes to the
HTML API (say some new element / attribute that allows code execution
or some sort of API to allow data to execute as code)

Cheers
Devdatta

2009/10/29 Brandon Sterne <bst...@mozilla.com>:

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

[Ian G]

On 30/10/2009 05:58, Brandon Sterne wrote:

> Please feel free to add any additional criteria that seem appropriate.

x. Think like an attacker. How easy is the model to bypass (most
likely) or breach (rare, mostly academic) ?

x. Think like an architect. Does this lead us forward towards a better
sustainable defence? Is this the first step to fixing the real
problems? Does it make more obvious what underlying API changes are
needed? Or is it a stop gap measure that will be breached eventually?
Does it paper-over the underlying bugs? Is this encouraging a better
asymmetry in defence (good) or encouraging the attack-defence cycle (bad)?

x. Think like an economist. How costly is it to attack overall? Does
this cost imposed on the attacker raise a barrier high enough to make a
difference? (Locks & neighours strategy.) How costly is it for a
company to implement this? Does the cost / barrier justify the
corporate expenses or is the company better off spending the money
elsewhere?

x. Think like a manager. How easy is the model to communicate? How
easy are the words & concepts? Does it deal with or hide the
complexity? PR: Does it fit well with a meme/hype campaign?

x. Think like a developer. How much fun is it to implement? How
difficult are the concepts & words? Does it surface and envelope with
its complexity? Does it get me jobs, beers, relationships?

x. Think like a pragmatist. Maybe we don't know, and maybe we won't
until we try it, no matter how many questions we ask. Stop waffling,
more list posts don't get more lines of code written, get back to work.

Some of these are slightly toungue in cheek :)

iang