forked from w3c/webappsec
-
Notifications
You must be signed in to change notification settings - Fork 1
/
webappsec-charter-2019.html
539 lines (392 loc) · 24.4 KB
/
webappsec-charter-2019.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=us-ascii">
<base href="https://www.w3.org/">
<title>DRAFT 2017 Web Application Security Working Group</title>
<link rel="stylesheet" href="/2005/10/w3cdoc.css" type="text/css" media="screen">
<link rel="stylesheet" type="text/css" href="/Guide/pubrules-style.css">
<link rel="stylesheet" type="text/css" href="/2006/02/charter-style.css">
</head>
<body>
<div id="template">
<ul id="navbar" style="font-size: small">
<li><a href="#scope">Scope</a></li>
<li><a href="#deliverables">Deliverables</a></li>
<li><a href="#coordination">Dependencies and Liaisons</a></li>
<li><a href="#participation">Participation</a></li>
<li><a href="#communication">Communication</a></li>
<li><a href="#decisions">Decision Policy</a></li>
<li><a href="#patentpolicy">Patent Policy</a></li>
<li><a href="#about">About this Charter</a></li>
</ul>
<p><a href="http://www.w3.org/" shape="rect"><img alt="W3C" height="48" src="/Icons/w3c_home"
width="72"></a></p>
<h1 id="title">DRAFT 2019 Web Application Security Working Group Charter</h1>
<p><strong>This is DRAFT PROPOSED CHARTER. Please send comments to <a href=
"mailto:public-webappsec@w3.org">public-webappsec@w3.org</a></strong></p>
<p class="mission">The <strong>mission</strong> of the <a href=
"http://www.w3.org/2011/webappsec/">Web Application Security Working Group</a> is to develop
security and policy mechanisms to improve the security of Web Applications, and enable secure
cross-origin communication.</p>
<div class="noprint">
<p class="join"><a href="http://www.w3.org/2004/01/pp-impl/49309/join">Join the Web
Application Security Working Group</a>.</p>
</div>
<table class="summary-table">
<tr id="Duration">
<th rowspan="1" colspan="1">End date</th>
<td rowspan="1" colspan="1">31 March 2021</td>
</tr>
<tr>
<th rowspan="1" colspan="1">Confidentiality</th>
<td rowspan="1" colspan="1">Proceedings are <a href=
"/2005/10/Process-20051014/comm.html#confidentiality-levels" shape="rect">public</a></td>
</tr>
<tr>
<th rowspan="1" colspan="1">Chairs</th>
<td rowspan="1" colspan="1">Dan Veditz, Mike West</td>
</tr>
<tr>
<th rowspan="1" colspan="1">Team Contacts<br>
(FTE %: 50)</th>
<td rowspan="1" colspan="1">TBD</td>
</tr>
<tr>
<th rowspan="1" colspan="1">Usual Meeting Schedule</th>
<td rowspan="1" colspan="1">Teleconferences: Monthly<br>
Face-to-face: 1-2 annually</td>
</tr>
</table>
<div class="scope">
<h2 id="scope">Scope</h2>
<p>Modern Web Applications are composed of many parts and technologies. They may transclude,
reference or have information flows between resources at the same, related or different
origins. Due to the historically coarse-grained nature of the security boundaries and
principals defined for such applications, they can be very difficult to secure.</p>
<p>In particular, application authors desire uniform policy mechanisms to allow application
components to drop privileges and reduce the chance they will be exploited, or that exploits
will compromise other content, to isolate themselves from vulnerabilities in content that
might otherwise be within the same security boundaries, and to communicate securely across
security boundaries. 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).</p>
<p>Areas of scope for this working group include:</p>
<dl>
<dt><b>Vulnerability Mitigation</b></dt>
<dd>
<p>Vulnerabilities are inevitable in sufficiently complex applications. The WG will work
on mechanisms to reduce the scope, exploitability and impact of common vulnerabilities and
vulnerability classes in web applications, especially script injection / XSS.</p>
</dd>
<dt><b>Attack Surface Reduction</b></dt>
<dd>
<p>The WG will design mechanisms to:</p>
<ul>
<li>Allow applications to restrict or forbid potentially dangerous features which they
do not intend to use</li>
<li>Govern information and content flows into and out of an application</li>
<li>Allow applications to isolate themselves from other content which may contain
unrelated vulnerabilities</li>
<li>Sandbox potentially untrusted content and allow it to be interacted with more
safely</li>
<li>Uniquely identify application content such that unauthorized modifications may be
detected and prevented</li>
<li>Replace or augment injection-prone APIs in the browser with safer alternatives
using strategies such as sanitization, strict contextual autoescaping, and other
validation and encoding strategies currently employed by server-side code.</li>
</ul>
</dd>
<dt><b>Secure Mashups</b></dt>
<dd>
<p>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:</p>
<ul>
<li>Allowing child IFRAMEs to protect themselves from "clickjacking"</li>
<li>Providing labeled information flows and confinement properties to enable secure
mashups. This is especially relevant for, e.g. applications communicating between
security principals with different user-granted permissions (e.g. geolocation)</li>
</ul>
</dd>
<dt><b>Manageability</b></dt>
<dd>
<p>Given the ad-hoc nature in which many important security features of the Web have
evolved, providing uniformly secure experiences to users is difficult for developers. The
WG will document and create uniform experiences for several undefined areas of major
utility, including:</p>
<ul>
<li>Treatment of Mixed HTTPS/HTTP Content and defining Secure/Authenticated Origins for
purposes of user experience, content inclusion/transclusion and other information
flows, and for features which require a verifiably secure environment</li>
<li>Providing hinting and direct support for credential managers, whether integrated
into the user-agent or 3rd-party, to assist users in managing the complexities of
secure passwords</li>
<li>Application awareness of features which may require explicit user permission to
enable.</li>
</ul>
</dd>
<dt><b>The Web Security Model</b></dt>
<dd>
<p>The WG may be called on to advise other WGs or the TAG on the fundamental security
model of the Web Platform and may produce Recommendations towards the advancement of, or
addressing legacy issues with, the model, such as mitigating cross-origin data leaks or
side channel attacks.</p>
</dd>
</dl>
<p>In addition to developing Recommendation Track documents in support of these goals, the
Web Application Security Working Group may provide review of specifications from other
Working Groups, in particular as these specifications touch on chartered deliverables of this
group (in particular CSP), or the Web security model, and may also develop non-normative
documents in support of Web security, such as developer and user guides for its normative
specifications.</p>
<h3>Success Criteria</h3>
<p>To advance to Proposed Recommendation, each specification is expected to have two
independent implementations of each feature described in the specification.</p>
<p>Each specification should contain a section detailing all known security and privacy implications for implementers, Web authors, and end users.</p>
<p>For specifications of technologies that directly impact user experience, each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.</p>
</div>
<div>
<h2 id="deliverables">Deliverables</h2>
<p>All of the following deliverables are on or proposed for the Recommendation Track:</p>
<dl>
<dt id="csp3" class="spec"><a href="https://www.w3.org/TR/CSP3/">Content Security Policy
Level 3</a></dt>
<dd>
<p>A policy language intended to enable web designers or server administrators to declare
a security policy for a web resource. 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. Content Security Policy (CSP) Level 3 succeeds CSP2, which is now a Recommendation.</p>
<p class="draft-status"><b>Draft state:</b> <a href="https://www.w3.org/TR/CSP3/">Working Draft</a></p>
<p class="milestone"><b>Expected completion:</b> [Q2 2019]</p>
</dd>
<dt class="spec"><a href="https://www.w3.org/TR/csp-embedded-enforcement/">Content Security
Policy: Embedded Enforcement</a></dt>
<dd>
<p>Define a mechanism by which a web page can embed a nested browsing context if and only
if it agrees to enforce a particular set of restrictions upon itself.</p>
<p class="draft-status"><b>Draft state:</b> <a href="https://www.w3.org/TR/csp-embedded-enforcement/">Working Draft</a></p>
<p class="milestone"><b>Expected completion:</b> [Q3 2019]</p>
</dd>
<dt><a href="http://www.w3.org/TR/mixed-content/">Mixed Content</a> </dt>
<dd>
<p>A recommendation for dealing with resources loaded over insecure channels in a secure
web application. Use cases includes standard behaviors for user agents to follow when
encountering insecure resource loads in a secure context.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2016/CR-mixed-content-20160802/">Candidate Recommendation</a></p>
<p class="milestone"><b>Expected completion:</b> [Q1 2019]</p>
</dd>
<dt><a href="https://www.w3.org/TR/upgrade-insecure-requests/">Upgrade Insecure
Requests</a></dt>
<dd>
<p>Create a mechanism to assist in sites migrating from HTTP to HTTPS by allowing them to
assert to a user agent that they intend a site to load only secure resources, and that
insecure URLs ought to be treated as though they had been replaced with secure URLs.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2015/CR-upgrade-insecure-requests-20151008/">Candidate
Recommendation</a></p>
<p class="milestone"><b>Expected completion:</b> [Q1 2019]</p>
</dd>
<dt><a href="https://www.w3.org/TR/secure-contexts/">Secure Contexts</a></dt>
<dd>
<p>A recommendation defining "secure contexts", thereby allowing user agent implementers
and specification authors to enable certain features only when certain minimum standards
of authentication and confidentiality are met.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2016/CR-secure-contexts-20160915/">Candidate
Recommendation</a></p>
<p class="milestone"><b>Expected completion:</b> [Q1 2019]</p>
</dd>
<dt><a href="http://www.w3.org/TR/clear-site-data/">Clear Site Data</a> </dt>
<dd>
<p>Define an imperative mechanism which allows web developers to instruct a user agent to
clear a site’s locally stored data related to a host.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2016/WD-clear-site-data-20160720/">Working Draft</a></p>
<p class="milestone"><b>Expected completion:</b> [Q4 2019]</p>
</dd>
<dt><a href="http://www.w3.org/TR/referrer-policy/">Referrer Policy</a></dt>
<dd>
<p>A recommendation for a header and meta tag allowing resource authors to specify a
policy for the values sent as part of the HTTP Referer (sic) header. Use cases include
making this policy more restrictive to protect applications which include security
capability tokens in the URL, or allowing more permissive sharing of referrer information
from secure to insecure origins to remove barriers which today prevent applications from
moving to secure origins.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2017/CR-referrer-policy-20170126/">Candidate Recommendation</a></p>
<p class="milestone"><b>Expected completion:</b> [Q1 2019]</p>
</dd>
<dt><a href="https://www.w3.org/TR/credential-management-1/">Credential Management
API</a></dt>
<dd>
<p>Create and advance recommendation(s) for a standardized API to address use cases
related to assisted management of user credentials, including traditional
username/password pairs, username/federated identity provider pairs. The API should allow
for explicit and interoperable imperative mechanism for use and lifecycle management of
these common credential types.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2016/WD-credential-management-1-20160425/">Working Draft</a></p>
<p class="milestone"><b>Expected completion:</b> [Q1 2019]</p>
</dd>
<dt><b>Subresource Integrity Level 2</b></dt>
<dd>
<p>Build on the <a href="https://www.w3.org/TR/SRI/">Subresource Integrity</a>
Recommendation in order to:</p>
<ul>
<li>improve the ability to deploy and manage integrity taggging of assets for complex
applications, including but not limited to mechanisms such as policy, manifests and
public key signatures</li>
<li>explore the possibility of verifying entire packaged web applications units with a
goal of providing end-user assurance about the identity and integrity of the code they
are interacting with</li>
</ul>
</dd>
<dt><b>Suborigins</b></dt>
<dd>
<p>Create and advance a recommendation to allow applications to place themselves into
namespaces within a traditional scheme/host/port RFC 6454 Origin label to enable easier
development of modular applications with privilege separation.</p>
<p class="draft-status"><b>Draft state:</b> UNOFFICIAL <a href=
"https://w3c.github.io/webappsec-suborigins/">Editor's Draft</a></p>
</dd>
<dt><b>Origin-Wide Policy</b></dt>
<dd>
<p>Work on mechanisms
to provide security policy statements that apply to an entire origin.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://wicg.github.io/origin-policy/">WICG incubation discussion</a></p>
</dd>
<dt><b><a href="https://www.w3.org/TR/permissions/">Permissions API</a></b></dt>
<dd>
<p>Create and advance a recommendation to allow web applications to be aware of the
status of a given permission, to know whether it is granted, denied, or if the user will
be asked whether the permission should be granted. This recommendation will not address
user agent implementations of permissions, including their scope, duration, granularity,
or user interface and experience for indicating, configuring, or asking for
permissions.</p>
<p class="draft-status"><b>Draft state:</b> <a href=
"https://www.w3.org/TR/2015/WD-permissions-20150407/">First Public Working Draft</a></p>
<p class="milestone"><b>Expected completion:</b> [Q4 2019]</p>
</dd>
<dt><b><a href="https://w3c.github.io/webappsec-feature-policy/">Feature Policy</a></b></p>
<dd><p>
A web platform API which gives a website the ability to allow and deny the use of browser features in its own frame, and in iframes that it embeds. </p>
<p class="draft-status"><b>Draft state:</b> Adopted from <a href="https://github.com/WICG/feature-policy">WICG incubation</a>.</p>
<p class="milestone"><b>Expected completion:</b> [Q2 2020]</p>
</dd>
</dl>
<div class="dependencies">
<h2 id="coordination">Dependencies and Liaisons</h2>
<h3>W3C Groups</h3>
<dl> <dt><a href="https://www.w3.org/WebPlatform/WG/">Web Platform WG</a></dt>
<dd>The WG may coordinate with Web Platform WG around API design.
The <a href="https://www.w3.org/TR/html5/">HTML</a> specification defines many of the
security policies that apply in the current browser environment, and Subresource
Integrity defines new attributes that may be applied to HTML tags.</dd>
<dt><a href="https://www.w3.org/Privacy/">Privacy Interest Group</a></dt>
<dd>The WG may ask the Privacy Interest Group to review some of its specifications for
privacy considerations.</dd>
<dt><a href="https://www.w3.org/Security/wiki/IG">Web Security Interest Group</a></dt>
<dd>The WG may ask the Web Security Interest Group review some of its specifications for
security considerations.</dd>
<dt><a href="https://www.w3.org/2001/tag/">Technical Architecture Group (TAG)</a></dt>
<dd>The WG may ask the Technical Architecture Group to review some of its
specifications.</dd>
<dt><a href="https://www.w3.org/WAI/APA">Accessible Platform Architectures Working Group</a></dt>
<dd>The WG may ask APA to review some of its specifications for potential
accessibility issues.</dd>
<dt><a href="https://www.w3.org/Webauthn/">Web Authentication Working Group</a></dt>
<dd>The WG will liaise with the Web Authentication WG on Credential Management.</dd>
<dt><a href="https://www.w3.org/2009/dap/">Device and Sensors Working Group</a></dt>
<dd>The WG may work with the Device and Sensors WG on the security of their client-side APIs.</dd>
</dl>
<h3>Outside Groups</h3>
<dl>
<dt><a href="https://whatwg.org/">Web Hypertext Application Technology Working Group
(WHATWG)</a></dt>
<dd>Specifications such as CSP provide inputs into the algorithms defined by, e.g. the
Fetch specification and portions of CSP and Mixed Content may be defined in terms of
Fetch. WebAppSec will work with WHATWG Fetch to
ensure that CSP's normative dependencies on Fetch satisfy the W3C <a href="https://www.w3.org/2013/09/normative-references">normative
references policy</a>. </dd>
</dl>
</div>
<div class="participation">
<h2 id="participation">Participation</h2>
<p>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.</p>
</div>
<div class="communication">
<h2 id="communication">Communication</h2>
<p>This group conducts general discussion on the public mailing list
public-webappsec@w3.org (<a href=
"http://lists.w3.org/Archives/Public/public-webappsec/">archive</a>).</p>
<p>Discussion on issues related to specific deliverables is primarily conducted
through the use of GitHub issues. The WG's main GitHub repository is at
<a href="https://github.com/w3c/webappsec">https://github.com/w3c/webappsec</a>,
which links to individual repositories for each deliverable.</p>
<p>Information about the group (deliverables, participants, face-to-face meetings,
teleconferences, etc.) is available from the <a href=
"http://www.w3.org/2011/webappsec/">Web Application Security Working Group home
page</a>.</p>
</div>
<div class="decisions">
<h2 id="decisions">Decision Policy</h2>
<p>As explained in the Process Document (<a href="/Consortium/Process/policies#Consensus"
shape="rect">section 3.3</a>), 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 Chairs should put a question out for voting within the group
(allowing for remote asynchronous participation -- using, for example, email and/or
web-based survey techniques) and record a decision, along with any objections. The matter
should then be considered resolved unless and until new information becomes available.</p>
<p>Any resolution first taken in a face-to-face meeting or teleconference [i.e., that does
not follow a 7 day call for consensus on the mailing list] is to be considered provisional
until 5 working days after the publication of the resolution in draft minutes, available
from the WG's calendar or home page. If no objections are raised on the mailing list within
that time, the resolution will be considered to have consensus as a resolution of the
Working Group.</p>
</div>
<div class="patent">
<h2 id="patentpolicy">Patent Policy</h2>
<p>This Working Group operates under the <a href="/Consortium/Patent-Policy-20040205/"
shape="rect">W3C Patent Policy</a> (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.</p>
<p>For more information about disclosure obligations for this group, please see the
<a href="/2004/01/pp-impl/" shape="rect">W3C Patent Policy Implementation</a>.</p>
</div>
<section id="licensing">
<h2>Licensing</h2>
<p>This Working Group will use the <a href="https://www.w3.org/Consortium/Legal/copyright-software">W3C Software and Document license</a> for all deliverables.</p>
</section>
<h2 id="about">About this Charter</h2>
<p>This charter for the Web Application Security Working Group has been created according to
<a href="/Consortium/Process/groups#GAGeneral" shape="rect">section 5.2</a> of the <a href=
"/Consortium/Process" shape="rect">Process Document</a>. 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.</p>
<p>Please also see the <a href="https://www.w3.org/2015/03/webappsec-charter-2015.html">previous charter</a> for this group.</p>
<hr>
<address>
Mike West, Dan Veditz, Wendy Seltzer <<a href=
"mailto:wseltzer@w3.org">wseltzer@w3.org</a>>
</address>
<p class="copyright"><a rel="Copyright" href="/Consortium/Legal/ipr-notice#Copyright" shape=
"rect">Copyright</a> © 2016-2017 <a href="/" shape="rect"><acronym title=
"World Wide Web Consortium">W3C</acronym></a> <sup>®</sup> (<a href=
"http://www.csail.mit.edu/" shape="rect"><acronym title=
"Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"
shape="rect"><acronym title=
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href=
"http://www.keio.ac.jp/" shape="rect">Keio</a>, <a href="http://ev.buaa.edu.cn/" shape=
"rect">Beihang</a>), All Rights Reserved.</p>
</div>
</div>
</body>
</html>