WebAppSec Updates from W3C

@thisNatasha
WebAppSec
Updates from W3C
Natasha Rooney
@thisNatasha
GSMA Web Technologist
W3C WebMob Co-Chair
www.w3.org/Mobile/IG/

@thisNatasha
Web features are getting more powerful.
Developers: how can we help developers make
better choices or protect their apps?
Users: how can we help protect users?
What’s happening?
Service Workers WebRTC
Geolocation Permissions

@thisNatasha
WebAppSec Working Group
…[T]he mission of the Web
Application Security Working
Group is to develop technical
and policy mechanisms to
improve the security of and
enable secure cross-site
communications for
applications on the Web.
Mailing List public-webappsec@w3.org
Website www.w3.org/2011/webappsec/

@thisNatasha
WebAppSec: Goals
[1] Attack Surface Reduction: allow applications to
restrict or forbid dangerous features
[2] Secure Mashups: mechanisms for secure
resource sharing and messaging across origins
[3] Manageability: Uniform policy control points
from which to manage these risks
[4] Develop a policy mechanism: standardized
means for security policy declaration

@thisNatasha
WebAppSec: Work
2015 Charter
Content Security Policy (CSP) Lvl 2, Lvl X
User Interface Security Directives for CSP
Mixed Content (MIX)
Sub Resource Integrity
Referrer Policy
Credential Management API
Suborigin Namespaces
Confinement with Origin Web Labels
Entry Point Regulation for Web Apps
Permissions API

@thisNatasha
Let’s go through
some work!
Clear Site Data
COWL
Credential Management
Other Updates

@thisNatasha
Clear Site Data
W3CFirstPublicWorkingDraft
Draft:
https://w3c.github.io/webappsec-clear-site-data/
Charter: 2015

@thisNatasha
Clear Site Data
Draft:
Charter: 2015
“Instruct a user agent to clear a site’s locally stored
data related to a host.”
- Web Applications store data on user’s computer
- Data is sensitive and valuable
- Some removed via JavaScript, others not:
Cookies: OK
HTTPonly cookies: Not OK
Cache: Not OK

@thisNatasha
Clear Site Data: Examples
Draft:
Charter: 2015
Signs out of “Super Secret Social Network” via a CSRF-protected POST
The site author wishes to ensure that locally stored data is removed.
Response HTTP header:
https://supersecretsocialnetwork.example.com/logout
// Signing Out / Kill Switch
Clear-Site-Data: *
// Keep Critical Cookies
Clear-Site-Data: storage; executionContexts; cache

@thisNatasha
Clear Site Data: Example 2
Draft:
Charter: 2015
Target a specific app subdomain by including a request to that
subdomain as part of the logout landing page:
- Request’s preflight return: proper CORS headers
- Actual requests return header:
fetch("https://minus.megacorp.example.com/clear-site-data",
{
method: "POST",
mode: "cors",
headers: new Headers({
"CSRF": "[insert sekrit token here]"
})
});
Clear-Site-Data: *

@thisNatasha
Confinement with Origin Web Labels (COWL)
W3CWorkingDraft
Draft: https://w3c.github.io/webappsec-cowl/
Charter: 2015

@thisNatasha
W3CWorkingDraft
Charter: 2015
“Specifying privacy and integrity policies on data, in
the form of origin labels, and a mechanism for
confining code according to such policies.”
- third party scripts puts user’s data confidentiality and
integrity at risk!
- CORs and CSP can help!
- But not where that data can be used...

@thisNatasha
W3CWorkingDraft
Charter: 2015
COWL:
- developer states that a password is confidential to https://example.com
- It can then be shared with (e.g.) a third-party password checker.
- The third-party password checker is confined and respects the policy
on the password:
COWL disallows it from disclosing the password to
any origin other than https://example.com.
- Confines code at the Context Level
- Developers can set restrictions on shared data
- Stop code from being shared outside specified origins
- Can compartmentalise apps to specify privileges

@thisNatasha
COWL: Example
Confining untrusted third-party services
W3CWorkingDraft
Charter: 2015
- https://example.com wishes to use the untrusted
https://passwordcheck.com
- https://example.com uses COWL to add a confidentiality policy (a
label) to the password before sending it to https://passwordcheck.com
// Create new policy using Labels that specifies that the password is sensitive
// to https://example.com and should only be disclosed to this origin:
var policy = new Label(window.location.origin);
// Associate the label with the password:
var labeledPassword = new LabeledObject(password, {confidentiality: policy});
// Send the labeled password to the checker iframe:
checker.postMessage(labeledPassword, "https://untrusted.com");
// Register listener to receive a response from checker, etc.

@thisNatasha
COWL: Example
Confining untrusted third-party services
W3CWorkingDraft
Charter: 2015
1. https://passwordcheck.com checks the password
2. COWL limits the iframe to communicating with origins that preserve the
password’s confidentiality (https://example.com).
3. This “policy” is enforced mandatorily
4. https://passwordcheck.com cannot send the password elsewhere
Note: https://passwordcheck.com can communite with other origins before
inpecting the password.
// Create new policy using Labels that specifies that the password is sensitive
// to https://example.com and should only be disclosed to this origin:
var policy = new Label(window.location.origin);
// Associate the label with the password:
var labeledPassword = new LabeledObject(password, {confidentiality: policy});
// Send the labeled password to the checker iframe:
checker.postMessage(labeledPassword, "https://untrusted.com");
// Register listener to receive a response from checker, etc.

@thisNatasha
COWL: Examples
Sharing data with mashups / privilege separation
W3CWorkingDraft
Charter: 2015
- https://example.com wishes to allow https://mashup.com access to data.
- Server operator can set COWL response header to:
1. https://mashup.com can access data through CORs
2. COWL header says data can only be shared with https://example.com
- Give different privileges according to users.
1. Content of user1 does not interfere with any other user.
2. Content of user1 cannot leak anywhere else.
Access-Control-Allow-Origin: https://mashup.com
Sec-COWL: data-confidentiality [ ["https://example.com"] ]
Sec-COWL: ctx-privilege [ ['self', 'cowl://user1'] ]

@thisNatasha
W3CWorkingDraft
Draft:http://w3c.github.io/webappsec-credential-
management/
Charter: 2015

@thisNatasha
W3CWorkingDraft
management/
Charter: 2015
“[R]equest a user’s credentials from a user agent, and to help
the user agent correctly store user credentials for future use”
- Autofilled credentials
- Hard for some use cases: e.g. credentials sent through XHR
- Credential Manager API can help!

@thisNatasha
Credential Management:
Password-based Sign-in
W3CWorkingDraft
management/
Charter: 2015
navigator.credentials.get({ "password": true }).then(
function(credential) {
if (!credential) {
// The user either doesn’t have credentials for this site, or
// refused to share them. Insert some code here to show a basic
// login form (or, ideally, do nothing, since this API should
// really be progressive enhancement on top of an existing form).
return;
}
if (credential.type == "password") {
fetch("https://example.com/loginEndpoint", { body: credential.toFormData(),
method: "POST" })
.then(function (response) {
// Notify the user that signin succeeded! Do amazing, signed-in things!
});
} else {
// in Spec: federated sign-in example
}
});

@thisNatasha
WebAppSec: Other Updates
Spec Updates
- Candidate Recommendation: Subresource Integrity
- Candidate Recommendation: Mixed Content
- Password generation in Credential Manager
- Published: COWL
- Referrer turned into a distinct header
- Mixed Content and DASH
- Permissions API Working Draft
- HSTS, mixed content, and priming: fetch resources using HTTPS even if
the URL uses the "http:"
Group Management Updates
- Specs now on Github
- Berlin Face-to-Face

@thisNatasha
WebAppSec: At TPAC
TPAC 2015 29-30 October
- Credential Management
- Content Security Policy
- Referrer Policy
- Joint session with Web Payments WG on secure API design
- COWL
- CSP Embedded Enforcement
Agenda Link

@thisNatasha
ありがとう！
Natasha Rooney
@thisNatasha
GSMA Web Technologist
W3C WebMob Co-Chair
www.w3.org/Mobile/IG/
Thanks to Brad Hill (Chair) &
Mike West (editor)
from the WebAppSec WG!

@thisNatasha
Unused Slides Past this Point!

@thisNatasha
Clear Site Data
Draft:
Charter: 2015
General Syntax:
Clear-Site-Data = 1#option
option = parameter *( OWS ";" [ OWS parameter ] )
parameter = key [ BWS "=" value ]
key = token
value = token / quoted-string
// Parameters:
// cache, cookies, storage, executionContexts, *

@thisNatasha
Content Security Policy (CSP)
W3CCandidateRecommendation
Draft: www.w3.org/TR/CSP/
http://content-security-policy.com/
Charter: 2013 & 2015

@thisNatasha
Content Security Policy (CSP)
The Web Security Model is based on “Same Origin Policy”
● Code from https://mybank.com should only have access to
https://mybank.com’s data
● https://evil.example.com should certainly never be allowed
access.
Content Security Policy is a HTTP Header which can help!
Draft: www.w3.org/TR/CSP/
http://content-security-policy.com/
Charter: 2013 & 2015
Content-Security-Policy: default-src 'self'; img-src *; media-src
media1.com media2.com; script-src userscripts.example.com

@thisNatasha
CSP 2: What’s Different?
New things in Content Security Policy Level 2 include:
[1] New “Delivery Methods”
e.g HTML <meta> element
[2] Dealing with multiple policies
all will be obeyed!
[3] Dealing with Workers!
How do we deal with Shared or ServiceWorkers?
[5] New Directives
e.g. referrer, plugin-types, form-action, frame-ancestors
Charter: 2015
Draft: www.w3.org/TR/CSP2/

@thisNatasha
Subresource Integrity (SRI)
W3CWorkingDraft
Draft: www.w3.org/TR/SRI/
Charter: 2015

@thisNatasha
Subresource Integrity (SRI)
Security Measures
E.g. TLS, HSTS, and pinned public keys
authenticate only the server,
not the content.
Attacker can still change content!
W3CWorkingDraft
Draft: www.w3.org/TR/SRI/
Charter: 2015
<script src="https://code.jquery.com/jquery-1.10.2.min.js"
integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?
ct=application/javascript">

@thisNatasha
Referrer Policy
W3CWorkingDraft
Draft: www.w3.org/TR/referrer-policy/
Charter: 2015

@thisNatasha
Referrer Policy
Referrer Policy says what a site should do about the
Referrer Header.
How do you do it?
[1] Content Security Policy (CSP) directive
[2] Content Security Policy (CSP) meta tag
[3] Via a meta element with a name of referrer.
[4] Implicitly, via inheritance.
W3CWorkingDraft
Draft: www.w3.org/TR/referrer-policy/
Charter: 2015

@thisNatasha
Mixed Content
W3CWorkingDraft
Draft: www.w3.org/TR/mixed-content/
Charter: 2015

@thisNatasha
Mixed Content
Does your HTTPS site contain content with HTTP links?
Then you have MIXED CONTENT!
MIxed Content details how user agents should treat
these resources.
W3CWorkingDraft
Draft: www.w3.org/TR/mixed-content/
Charter: 2015

@thisNatasha
Do we need to do more?
How powerful are Powerful Features?
Can features become too powerful? Do we need to enforce
HTTPS or other measures for these APIs?
Do we need full HTTPS?
The IAB supported HTTPS for new protocol
development. Should the W3C do the same thing?

@thisNatasha
Powerful Features Document
https://w3c.github.io/webappsec/specs/powerfulfeatures/

@thisNatasha
Powerful Features Document
https://w3c.github.io/webappsec/specs/powerfulfeatures/
[1] How can web features (APIs) be abused?
[2] Categorising
- access to sensitive data? (Credential Management)
- access to a sensor? (Geolocation)
- holds state of origin? (Service Workers)
- Permission is required?
[3] Defining some algorithms
Using TLS, HTTPS, localhost, file, packaged, preconfigured = Trusted
Otherwise not Trusted

@thisNatasha
Transition to HTTPS
https://github.com/w3ctag/web-https

@thisNatasha
Transition to HTTPS
https://github.com/w3ctag/web-https
“Therefore, the TAG finds that the Web platform should be
designed to actively prefer secure origins — typically, by
encouraging use of HTTPS URLs instead of HTTP ones.
Furthermore, the end-to-end nature of TLS encryption must
not be compromised on the Web, in order to preserve this
trust.”

@thisNatasha
Clear Site Data: Open Issues
Draft:
Charter: 2015
- Integrating with Fetch
- Still in control of Web Developer, not the user
- No github issues!

WebAppSec Updates from W3C

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to WebAppSec Updates from W3C

Similar to WebAppSec Updates from W3C (20)

More from Natasha Rooney

More from Natasha Rooney (13)

Recently uploaded

Recently uploaded (20)

WebAppSec Updates from W3C