Re: Trimming the SecurityPolicy DOM interface

Responses inline.

Yehuda Katz
(ph) 718.877.1325


On Sat, May 25, 2013 at 11:04 PM, Hill, Brad <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.****
>
> ** **
>
> We definitely need to consider this perspective, and I look forward to
> Adam’s new proposal.
>

I fleshed out some of Alex's thoughts on my blog: An Extensible Approach to
Browser Security
Policy<http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/>

Note that I only really talked about the relationship of CSP to the network
layer, but similar principles would apply to restricting eval (by using the
new ES6 module loader).

 ****
>
> 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.
> 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.
>
One of the great things about the NavigationController proposal is that the
controller JavaScript executes outside of the window, and once it's
installed, it cannot be affected by future shenanigans on the page.

I would even be in favor of an even more declarative and tamper-proof form
of controller installation (either via a header like NavigationController:
<jsfile> or via an attribute on the html tag).


>  ****
>
> 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 L) and
> I am very proud of our conservatism and success so-far in this task for CSP
> 1.0.
>
I agree with this principle, and it makes sense for security. Additionally,
for CSP 1.0, you didn't have access to a mechanism like
NavigationController, which allows you to make better
declarative/imperative tradeoffs than you were able to make before.

That said, the declarative form of CSP is exactly as fine-grained as the
developers of CSP thought to make it. In general, declarative forms like
CSP are good at hitting the 80 or 90% case, but can never hit all
real-world cases (and shouldn't try to). An imperative escape valve allows
web application developers to experiment with different policies, and
provides a nice way to feed those policies back into the platform.

> 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.
>
This thinking argues precisely for the kind of factoring Alex has been
advocating for. By defining the high-level, normally used mechanism in
terms of a lower-level imperative mechanism, you can make it extremely easy
for the masses of developers to build more easily secured applications,
while giving "elite" developers the tools to try out alternative policies
and feed them back into the system.

It's worth noting that in the JavaScript space, libraries and framework
often serve this role. Average developers use the tools produced by "elite"
developers when broad use-cases emerge that were not considered by the
original high-level forms.

Also, as more and more APIs are built to interact with the network
layer,*it will become a security hazard to have them all defined
orthogonally
* instead of in terms of a shared primitive. If you define the CSP behavior
as the default behavior of the NavigationController, for instance, it is
clear how it interacts with NavigationController as well as other APIs that
use NavigationController as their primitive.

Defining as many features as you can in terms of a few shared primitives
avoids introducing new security surface area over time, because the
security effort is focused on the primitives, not each new feature.

> 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.   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.
>
I never had any doubt about that. These problems are genuinely hard, and
slapping together a bad imperative solution is worse than skipping one for
now.

Alex wrote on his blog:

There is, of course, another option: CSP 1.1 could punt on an API entirely.
> That’s a coherent position that eliminates these frictions, and I’m not
> sure it’s a bad option given how badly the API has been mangled
> recently. But it’s not the best solution.


I believe that honestly reflects his position.

As a web developer working one layer down the stack (mostly providing
libraries and frameworks for web developers further down the stack), what
Alex said has the ring of truth to me. You can look at what happened with
AppCache to see what happens when high-level API designers make mistakes
but don't provide any imperative escape valve.

I think we want the virtuous circle I described in Extend the Web
Forward<http://yehudakatz.com/2013/05/21/extend-the-web-forward/> just
as much for security as we do for any other part of the web platform (if
not more).

>  ** **
>
> Cheers,****
>
> ** **
>
> Brad****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Alex Russell [mailto:slightlyoff@google.com]
> *Sent:* Friday, May 24, 2013 10:02 AM
> *To:* Adam Barth
> *Cc:* 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****
>
> ** **
>
> 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>
> 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> 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
> >>
> >****
>