RE: New proposed charter and chairs for WebAppSec WG

Yes, the unofficial CSP draft (https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html) is a major deliverable which this group would continue to advance along Recommendations Track - I didn't mean to imply otherwise and have zero desire to start over with the excellent work you've done there in both specification and implementation.

Re: manageability.  The philosophy of the CSP is exactly the sort of thing I'm driving at with manageability as a top-level concern, as a positive example vs. e.g., having to manage the attributes of every tag in every resource on a domain.  The value judgment is that security policy  must be available at the same scope as the security guarantees which depend on it.  So, if a single XSS can compromise the security of an entire origin's applications, it should be possible to specify and apply anti-XSS policies at the level of the entire origin.  There's a huge history of vulnerabilities to show why this is important.  

I'm aware of the discussion here, as far as headers vs/and/or in addition to, a well-known policy location, controversy about adding extra requests, and appreciate the conservative instinct there in creating a first implementation.  I included it in the charter proposal because I feel that policy scope, advertisement and deployment mechanisms are still relevant and live topics for advancement and discussion in the WG from a variety of perspectives.

Is your opinion otherwise, that this is a settled issue and should be out of scope?

-Brad

-----Original Message-----
From: Brandon Sterne [mailto:bsterne@mozilla.com] 
Sent: Monday, June 06, 2011 3:03 PM
To: Hill, Brad
Cc: public-web-security@w3.org
Subject: Re: New proposed charter and chairs for WebAppSec WG

Hi Brad,

Thanks for the work that you, Eric, Thomas and Jeff have done to keep this ball rolling.  I'm particularly interested in this section that you added to the charter:

> Mechanisms which require individual declaration at every resource or element are impractical for large scale sites, and also unsuitable for legacy applications not under active maintenance. Web application administrators should have available a small number of uniform policy control points from which to manage these risks.
> 
> The Web Application Security (WebAppSec) Working Group will develop a policy mechanism providing web application administrators a standardized means for security policy declaration, based on the existing Content Security Policy specification.

These sentences seem to make a value judgment about the policy mechanism proposed in both the original Mozilla CSP proposal as well as the current Unofficial Draft that has been discussed for the past few months on public-web-security.  It's a position that I have not seen made or at least supported very strongly there, so I'm wondering why this language was added to the proposed charter.

Also, when you say the "existing Content Security Policy specification"
upon which the WG will be basing a new policy mechanism, what do you mean?  Isn't the Unofficial Draft that I have been editing the new thing?

Regards,
Brandon


On 06/06/2011 02:11 PM, Hill, Brad wrote:
> Greetings,
> 
> It has been a year now since Thomas proposed a strawman charter for a W3C working group to address some of the topics of this list.   There's been much ongoing work in other groups, and Mozilla's introduction of their CSP has advanced the ball significantly.  However, the need for official standardization and a WG remains, evidenced by significant interest at the recent Identity in the Browser and Web 2.0 Security and Privacy Workshops.  
> 
> Eric Rescorla and I have volunteered to co-chair this effort, and our next step is to revisit the charter.  Below, find my updated suggestion of charter language, based on Thomas's initial draft, (http://www.w3.org/2010/07/appsecwg-charter) with contributions from Thomas, Eric and Jeff Hodges.  I've included it as text to make inline discussion here on the list easier.
> 
> This group would be intended to develop and advance along the Recommendations Track existing work on CORS, UMP and CSP, and coordinate with other WGs, including in the IETF, to propose additional mechanisms necessary for attack surface management and secure mashup apps.
> 
> I look forward to lively discussion on this proposal here and working with many of you in the upcoming WG.
> 
> Sincerely,
> 
> Brad Hill
> Sr. MTS, Internet Standards and Governance PayPal Information Risk 
> Management
> cell: 206.245.7844 / skype: hillbrad
> email: bhill@paypal.com
> 
> --------------
> 
> 1. Scope
> 
> Modern Web Applications may be governed by numerous security policies which are documented in a number of specifications, including HTML5 and XMLHttpRequest. Unfortunately, these policies are not implemented uniformly across major web browsers and plugins, are inadequate for certain use cases. Because there is no standard, shared mechanism for declaring and enforcing policies it is not possible for sites to selectively declare the need to escape from some restrictions or to request enforcement of additional restrictions.
> 
> These issues are especially relevant for the many web applications which incorporate, or "mashup", other web application resources. That is, they comprise multiple origins (i.e., security principals).
> 
> Areas of scope for this working group include:
> 
> 	* Attack Surface Reduction: The WG will design mechanisms to allow applications to restrict or forbid potentially dangerous features which they do not intend to use, thus limiting the attack surface. 
> 
> 	* Secure Mashups:  Several mechanisms for secure resource sharing and messaging across origins exist or are being specified, but several common and desirable use cases are not covered by existing work, such as: allowing child IFRAMEs to protect themselves from "clickjacking" or specify what characteristics a parent window must allow.  The WG will design mechanisms and coordinate with existing and ongoing work in other forums to allow secure mashups.
> 
> 	* Manageability: The coarse-grained nature of security principals (origins) in web application security policies, (e.g. the Same Origin Policy) means that a security weakness in any origin's web application resources may create vulnerabilities for all web application resources of that origin, as well as for any other origins whose web applications interact with it.  Mechanisms which require individual declaration at every resource or element are impractical for large scale sites, and also unsuitable for legacy applications not under active maintenance. Web application administrators should have available a small number of uniform policy control points from which to manage these risks.
> 
> The Web Application Security (WebAppSec) Working Group will develop a policy mechanism providing web application administrators a standardized means for security policy declaration, based on the existing Content Security Policy specification.
> 
> The WebAppSec Working Group also will develop one or more recommendation(s) to enable secure, cross-origin applications, as joint work with the Web Applications Working Group, based on the current Cross Origin Resource Sharing and Uniform Messaging Policy specifications, as well as with the WhatWG, the IETF WebSec Working Group and other working groups as necessary. 
> 
> 1.1 Success Criteria
> 
> To advance to Proposed Recommendation, each specification is expected to have two independent implementations of each feature described in the specification.
> 
> 2. Deliverables
> 
> Content Security Policy
> 
> A policy language intended to enable web designers or server administrators to declare web application content security policy. The goal of this specification is to reduce attack surface by specifying overall rules for what content may or may not do, thus preventing violation of security assumptions by attackers who are able to partially manipulate that content.
> 
> Secure Cross-Origin Application Mechanisms
> 
> Create and advance existing recommendations specifying mechanisms necessary for secure mashup applications, including the Cross-Origin Request Sharing (CORS) and Uniform Messaging Policy (UMP), as well as mechanisms not addressed by currently chartered work, such as bi-directional parent/child IFRAME security policies.  Such recommendations will be harmonized and published as joint work with the W3C Web Applications Working Group, WhatWG, and IETF WebSec Working Group, as appropriate.
>  
> 
>

Received on Monday, 6 June 2011 22:42:24 UTC