·
Scope
Web Application Security Working Group
Charter
The
mission
of the Web Application Security
Working Group, part of the Security Activity, is to develop security and
policy mechanisms to improve the security of Web Applications, and enable
secure cross-site communication.
End date |
31 December 2014 |
Confidentiality |
Proceedings are public |
Initial Chairs |
Brad Hill (PayPal) |
Initial Team Contacts |
Thomas Roessler |
Usual Meeting Schedule |
Teleconferences: Weekly |
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, and 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 other web
application resources (mashups). That is, they comprise multiple origins (i.e.,
security principals).
Areas of scope
for this working group include:
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 a recommendation to enable secure, cross-origin
applications, as joint work with the Web Applications Working Group, based on
the current Cross Origin Resource Sharing specification.
To advance to
Proposed Recommendation, each specification is expected to have two independent
implementations of each feature described in the specification.
Content Security Policy (CSP)
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-Domain Resource Sharing (CORS)
Advance existing
recommendation-track documents specifying mechanisms necessary for secure
mash-up applications, based on the existing CORS specification. Such
recommendations will be published as joint work with the Web Applications
Working Group.
Secure Cross-Domain Framing (UI Security Directives for CSP)
Create and advance
existing recommendations specifying bi-directional parent/child policies to
enable secure mashup applications built around cross-domain framing. To express
necessary constraints and demands, this deliverable will re-use and extend the
policy language of the Content Security Policy deliverable with the goal of
creating uniform semantics for requirements currently disjoint in expression
and implementation across the CSP, the HTML5 IFRAME sandbox, and the
X-Frame-Options HTTP header. This work will be closely coordinated with the
IETF websec WG and other frame policy related work in the IETF in order to
avoid overlapping or conflicting specifications.
Secure Mixed Content
Create and advance
recommendation(s) for dealing with resources in a secure web application loaded
over insecure channels. Use cases
include:
·
Adding integrity
protections to sub-resource loads from HTML documents. This mechanism would
have the goals of allowing resource authors to either or both specify the exact
of cross-origin sub-resources and to allow optimistic loading of such resources
in a cache-friendly manner over insecure transports. This work would be coordinated with and
possibly be a joint deliverable with the HTML WG.
·
Standard behaviors for
user agents to follow when encountering insecure resource loads in a secure
context. This might include definitions
of “active” and “passive” content that must be blocked or can be loaded with a
warning, and possibly ways for secure applications to consume insecure but
non-sensitive resources (such as a weather feed)
Lightweight Isolated / Safe Content
Create and advance
recommendation(s) for lightweight isolation and safety mechanisms for composed
web applications. An iframe and postMessage
can provide a strong isolation barrier, but can requires
too many resources on the client and present an unfriendly API to developers
for some scenarios. The deliverable(s)
will describe mechanisms to compose applications from imported components while
isolating the application from malicious impacts of those components. Possible mechanisms include sandboxing and/or
safe sub-setting of ECMAScript or HTML.
Milestones |
|||||
Note: The group will document significant
changes from this initial schedule on the group home page. |
|||||
Specification |
FPWD |
LC |
CR |
PR |
Rec |
Content Security Policy |
(not applicable) |
(not applicable) |
November 2012 |
July 2013 |
September 2013 |
Secure Cross-Domain Resource Sharing |
(not applicable) |
May 2012 |
December 2012 |
July 2012 |
September 2013 |
UI Security Directives for CSP |
November 2012 |
August 2013 |
October 2013 |
December 2013 |
February 2014 |
CSP 1.1 |
December 2012 |
July 2013 |
September 2013 |
December 2013 |
February 2014 |
Secure Mixed Content |
June 2013 |
September 2013 |
December 2013 |
February 2014 |
April 2014 |
Lightweight Isolated Content |
August 2013 |
November 2013 |
January 2014 |
March 2014 |
August 2014 |
Web Applications Working
Group
This Working Group will develop
its secure cross-site resource sharing deliverable as joint work with the Web
Applications Working Group.
The HTML5 specification defines many of the
security policies that apply in the current browser environment.
The secure use of Web
Cryptography APIs depends on a strong application security model, and sites may
wish to use CSP to disable privileged APIs in certain contexts.
The IETF Web Security WG is chartered
to provide a Web Security problem statement and standardize a limited number of
selected specifications. This Working Group is expected to liaise and
collaborate closely with the WebSec Working Group. Coordination is, in
particular, expected with respect to the secure cross-domain framing
deliverable proposed in this charter, and ongoing work to document the
X-Frame-Options mechanism within the IETF.
To be successful,
the Web Application Security Working Group is expected to have 10 active
participants for its duration. Effective participation to Web Application
Security Working Group is expected to consume one day per week for chairs and
editors. The Web Application Security Working Group will allocate also the
necessary resources for building Test Suites for each specification.
This group
primarily conducts its work on the public mailing list public-webappsec@w3.org.
Information about
the group (deliverables, participants, face-to-face meetings, teleconferences,
etc.) is available from the Web Application Security Working Group home page.
As explained in
the Process Document (section
3.3), this group will seek to make decisions when there is consensus. When the
Chair puts a question and observes dissent, after due consideration of
different opinions, the Chair should record a decision (possibly after a formal
vote) and any objections, and move on.
This Working
Group operates under the W3C
Patent Policy (5 February 2004 Version). To promote the widest adoption of
Web standards, W3C seeks to issue Recommendations that can be implemented,
according to this policy, on a Royalty-Free basis.
For more
information about disclosure obligations for this group, please see the W3C Patent Policy
Implementation.
This charter for
the Web Application Security Working Group has been created according to section
6.2 of the Process
Document. In the event of a conflict between this document or the provisions
of any charter and the W3C Process, the W3C Process shall take precedence.
Copyright © 2012 W3C
® (MIT , ERCIM
, Keio), All Rights Reserved.
$Date: 2013/05/07
23:58:50 $