Declaring Security

re: Declaring Security

EricLaw [MSFT] — Thu, 09 Jul 2009 19:45:47 GMT

@CLHandbook: I think it's important to understand that this is a *proposal* and not something that has been implemented by any browser at this point. As described above, IE8's XSS Filter provides protection against common XSS attacks without requiring changes to websites to "opt-in."

re: Declaring Security

CLhandbook — Thu, 09 Jul 2009 11:24:00 GMT

Very interesting and it's nice to know that these benefits are implemented. This way we can search over the internet without much fear about XSS attacks. There are lots of web threats circulating now and it's nice to know that Mozilla works in protecting their users from these attacks.

re: Declaring Security

EricLaw [ex-MSFT] — Sun, 28 Jun 2009 19:24:15 GMT

Thanks, Gerv.

@hAl: That same complaint was made against IE's XSS filter: "Hey, sites won't bother fixing XSS holes because IE8 users are protected by the automatic XSS filter."

The same line of thinking suggests that cars ought not have seatbelts and airbags, because they lead to careless driving. While there's some sense in such an argument, fatality rates since the introduction of such mitigations suggest that the benefits still far outweigh the downside. I believe this will prove true for CSP as well.

Defense-in-depth is a very well proven philosophy when it comes to software security, and the site operators I've spoken to all recognize that features like the XSS Filter and declarative security mechanisms are necessarily additive, particularly considering browser adoption curves.

re: Declaring Security

hAl — Sun, 28 Jun 2009 11:28:53 GMT

@Gervase

You said: "New attack surface. Because CSP can only increase security, any holes in "CSP" would be holes in a non-CSP browser. Unless they can attack the CSP parser itself;"

But actually in many cases this might replace other security mechnisms and not nescesairily increase security but place it outside a site. And because the security is in a variety of browsers it adds attack surface if sites remove other security defences.

Whereas security mistiakes in a site only harm the site and the visiters of that site a security issues in a browser is exloitable might wider.

For websites considering security a extremely important feature to their site this is not good solution because they are unable to rely on all browsers implementing this flawlessly.

CPS might provide additional security but also has its possible risks if sites start relying on it to heavily

re: Declaring Security

qualitydirectory — Sat, 27 Jun 2009 07:30:14 GMT

I like CSP because it helps web developers and server administrators to define how content interacts on their sites. And it helps to detect attacks like XSS and data injection. But we need more improvement that helps site owners to prevent XSS attacks.

re: Declaring Security

Dan Veditz — Fri, 26 Jun 2009 22:27:09 GMT

We've argued ourselves about what the granularity of the policies should be. Origins felt like a workable chunk-size -- easily understood, useful, and compact enough for a header-based policy.

While it's easy to imagine scenarios where you'd want to whitelist paths or specific resources, we don't know if it'll be a common-enough need to be worth the added complexity. Definitely something to think about once we have a beta implementation for sites to play with.

re: Declaring Security

Gervase Markham — Fri, 26 Jun 2009 11:55:32 GMT

Hi Eric,

Thanks for the write-up, and I'm flattered to be credited as one of the sources for this idea.

Your possible risks are important; here is how CSP has addressed some of them:

* Plugins. Quite right - plugins are a law unto themselves. It's a larger problem to solve but, in the mean time, you can use CSP to disable them entirely or restrict plugin content to whitelisted sites, neither of which has been possible for site owners up to now.

* Misconfiguration. Always an issue. We hope CSP strikes a balance between being understandable and being flexible :-), and it "fails closed" if the policy is broken. Feedback on how to help people write better policies would be welcome.

* New attack surface. Because CSP can only increase security, any holes in "CSP" would be holes in a non-CSP browser. Unless they can attack the CSP parser itself; although we hope that the language is simple enough that we can write a secure parser for it :-)

* Debuggability. We take this very seriously; policy parsing errors are reported to the Firefox console, and policy violations can be reported to a collector script. This means that even users of non-CSP-aware browsers benefit, because the site owner gets tipped off more quickly about the vulnerability.

* Dynamic content. No security technology fits everyone. There are some complex pages, like these ones, for which CSP is difficult to implement. Fair enough. Trying to cover every scenario would come with a complexity cost.

* Adoption. Being a server-side technology, we hope that large sites which embed user content or provide CMSes which do will adopt CSP, thereby deploying its benefits across the web. EBay, Facebook, Wordpress, Moveable Type etc. I think memories of the last few Facebook worms will mean that Facebook Towers rejigs their site organization and adopts CSP pretty quickly.

Gerv

re: Declaring Security

EricLaw [MSFT] — Fri, 26 Jun 2009 01:29:27 GMT

@Keith: While we're on the topic, it's interesting to contrast declarative security against Content Advisor (which, incidentally, is still in use in some parts of the world).

Content Advisor is based on a system whereby either a site describes its own "Rating" or a trusted reputation service (called a "Ratings Bureau") provides a rating for them.

The first scenario suffers from the problem that a given site may not elect to comply and identify its content, and therefore a child/restricted user would be able to view the site. Thus, you would be correct to note that, because a site may not describe its own policy via CSP, that site would find itself at risk of attacks possibly mitigated by CSP.

I'm not aware of any broadly used "Ratings Bureaus" for Content Advisor (as this feature is basically now legacy, replaced by Windows Vista Parental Controls and Windows Live Family Safety products) though they may exist in other locales.

re: Declaring Security

EricLaw [MSFT] — Fri, 26 Jun 2009 01:21:07 GMT

@Keith: A key design point for declarative security is that it's not the "user" making the security decision, it's the site owner. As I mentioned, there is the risk of misconfiguration, but that would be a mistake on the part of the developer/admin, not the end-user.

A layer 7 proxy appliance could *enforce* a security policy, but only if it knows what the policy should be. Declarative security directives enable user-agents to know what the policy should be.

@stefan: In the CSP proposal, your site would simply describe your desired policy in a policy file; the CSP header would point to that policy file. CSP currently does not seem to offer granularity to the level you're looking for (e.g. down to the specific target URL) and this is probably feedback you should provide over on the "Talk" page.

In terms of tooling, yes, I'd expect that if CSP is implemented and deployed, tools will be developed to help site owners author policy directives. For instance, you could probably easily write a Fiddler addin that emits a "your current policy" file, based on what a crawl of an existing site turns up.

re: Declaring Security

Keith Adler — Fri, 26 Jun 2009 00:18:40 GMT

While this seems like a good idea on the surface, I think leaving it to users to try to comprehend what these settings widens the vulnerability surface of the browser. It's very likely this feature would be the next "Content Advisor" feature; something that exists and no one complies with or uses. I would much rather see layer 7 proxies and appliances continue to worry about this.