RE: Trimming the SecurityPolicy DOM interface

I think some common ground is being exposed here - Yehuda's comments about NetworkController were especially illuminating for me, along with Alex's notion  that "there's a SecurityPolicy object back there somewhere, just let me at it!".

We've actually been having this kind of "big picture" debate in the last month: If CSP is the declarative, coarse-grained way to manage security policy, is there a need for an "advanced" imperative API, and (assuming yes) what should it look like?

I'm actually a big proponent of an advanced, imperative security API, and I love the idea of being able to get this service for your resources in a marketplace, as a library or a subscription, or whatever.

My question is - is a direct reflection of CSP into the DOM the right imperative API?  At an even higher level, should these two things be literally the same construct and specification?  Is exposing a set of one-way properties to the DOM really what the advanced user wants?  Should we continue to embellish the declarative use case with every nuance the imperative use cases need?  Is that the simplest and best way to approach the problem?

We've written new charter language to attempt to tackle this issue - should we standardize some kind of sandboxing or imperative technology in addition or as a complement to CSP?

Maybe we'd be much better off to provide hooks to create an imperative reference monitor script and identify the right places to impose that? (NetworkController, script parsing, DOM subscriptions, whatever...)  And maybe convergence means that eventually CSP is implemented in terms of this advanced feature rather than the other way around.

Interested to hear your (and others, of course) thoughts on this, Alex...

-Brad

From: Alex Russell [mailto:slightlyoff@google.com]
Sent: Tuesday, May 28, 2013 11:15 AM
To: Hill, Brad
Cc: Adam Barth; public-webappsec@w3.org; Mike West; www-tag@w3.org List; Anne van Kesteren; Yehuda Katz; Marcos Caceres
Subject: Re: Trimming the SecurityPolicy DOM interface

On Sat, May 25, 2013 at 11:04 PM, Hill, Brad <bhill@paypal-inc.com<mailto:bhill@paypal-inc.com>> wrote:
Thanks, Alex, for your careful thoughts here, and I venture we're all proud that you think so highly of CSP.

Hey Brad,

I do! CSP is incredible. I can't wait for it to be ubiquitous.


We definitely need to consider this perspective, and I look forward to Adam's new proposal.

However...I think that the situation with CSP does have some unique characteristics that make it different than the typical feature and merit some consideration.   I hope I can express our motivations here as well as you did yours.
First, CSP has a somewhat adversarial relationship with the DOM.  It begins with the assumption that the DOM may not be quite trustworthy.

That's entirely OK. I'm not suggesting implementing CSP in the DOM of the document that is being controlled.  Instead what I'm suggesting is that you should be designing the API as though it were being used to implement the feature. That's a completeness and accuracy check on the API. Reasoning about what to expose from a straight de-sugaring can happen orthogonally. It's not clear to me that there are any real issues here, however: the declarative API would only be subverted if the rules the system was enforcing were mutable from the page. I don't imagine anyone here is proposing such an API (except perhaps for the addition of new restrictions at runtime).

Version 1.0 lacks any sort of DOM API precisely because it had a design goal of being "out of band" to everything that goes into constructing the content of a dynamic resource.  We are walking that back only with compelling evidence of necessity.

I don't think that's the right frame for any API design. You'd be better off not exposing anything than doing a secenario-solving exercise in which you're pulled by the winds of who can yell at you loudest in this version or the next.

Next, as a security mechanism, we worked from a "first, do no harm" principle.  We didn't want there to be any way for an adversary to use CSP to make a resource less secure.   Reflected XSS filters offer a good lesson in the pitfalls of this type - clever folks found ways to abuse the mechanism to introduce XSS where none existed before, or to, e.g. disable frame-busting code intended to protect against clickjacking.   It turns out "do no harm" is very hard (if you stay tuned into this list, you'll see Peleus drop a nuclear bomb of this sort on my UISecurity work soon :() and I am very proud of our conservatism and success so-far in this task for CSP 1.0.

Finally, we have sought, often against our own instincts, to Keep It Simple.   As security professionals, we are aware that subtle and complex mechanisms are preferred by careful-thinking developers that want to maximize the security of their applications.  Those same careful-thinking developers are typically the loudest voices contributing to the specification process -- but they are also the audience that is least in need of useful security mechanisms.  They will do a good job of producing a secure application anyway.  There may be much more value to add to the ecosystem by producing a mechanism that is simple to understand and deploy, without the "gotchas" that tend to piggyback on the subtlety that the truly elite developers crave.  A dynamic, one-way policy mechanism that works sometimes, doesn't work other times, and introduces another piece of critical state to track across the execution context of a complex application, is tricky in the extreme and likely to be used incorrectly.

I hope this doesn't come off as too defensive, but I hope it does convince you that we're not just overworked here, but do have legitimate and carefully considered motivations behind our choices so far.

I have spent time in the trenches as a security professional in a past life. You don't have to apologize to me for being conservative; only for fielding bad API ;-)

  Creating something that's generative and finds creative uses beyond those we imagined is surely every author's highest ambition and  greatest satisfaction, so thank you for your contributions in pushing us towards that.  Powerful articulations of the goals of imaginative and ambitious users are the best help we can have to find the careful balance we're seeking.

Cheers,

Brad




From: Alex Russell [mailto:slightlyoff@google.com<mailto:slightlyoff@google.com>]
Sent: Friday, May 24, 2013 10:02 AM
To: Adam Barth
Cc: public-webappsec@w3.org<mailto:public-webappsec@w3.org>; Mike West; www-tag@w3.org<mailto:www-tag@w3.org> List; Anne van Kesteren; Yehuda Katz; Marcos Caceres

Subject: Re: Trimming the SecurityPolicy DOM interface

Apologies for not replying more fully before.

I've spent some time putting my thinking on this in blog-post form:

http://infrequently.org/2013/05/use-case-zero/

On Saturday, April 27, 2013, Adam Barth wrote:
Alex, would you be willing to share the specific use cases you have in
mind?  We just want to make sure there are solid use cases for the
features in the spec.

Adam


On Sat, Apr 27, 2013 at 11:31 AM, Alex Russell <slightlyoff@google.com<mailto:slightlyoff@google.com>> wrote:
> I object to these changes in the strongest possible terms. If it is not
> possible to implement CSP policy enforcement on top of your API, it is not
> sufficient.
>
> On Apr 27, 2013 5:46 PM, "Adam Barth" <w3c@adambarth.com<mailto:w3c@adambarth.com>> wrote:
>>
>> As discussed at the face-to-face meeting, I've trimmed the
>> SecurityPolicy DOM interface to just the first four attributes:
>>
>> https://dvcs.w3.org/hg/content-security-policy/rev/f338192860c5
>>
>> At the meeting, we discussed that these attribute have strong use
>> cases, but we couldn't think of any strong use cases for the remaining
>> DOM interfaces.
>>
>> If folks come up with strong use cases, we should consider adding back
>> the removed interfaces (or adding new interfaces that better address
>> those use cases).
>>
>> Note: At the face-to-face, we discussed making some of these attribute
>> writable in some circumstances, but I haven't made that change yet
>> because it probably deserves more discussion.
>>
>> Adam
>>
>