W3C

Web Application Security Working Group Teleconference

19 Nov 2013

Agenda

See also: IRC log

Attendees

Present
BHill, +1.781.369.aaaa, gmaone, gopal, wseltzer, +1.503.712.aabb, CCarson, terri, ekr, abarth, [Mozilla], grobinson, dveditz
Regrets
Chair
bhill2, ekr
Scribe
ekr

Contents


<trackbot> Date: 19 November 2013

<bhill2> :(

<bhill2> wseltzer, is Zakim not set for the end of daylight time in the US?

<bhill2> Meeting: WebAppSec WG Teleconference, 19-Nov-2013

<gopal> this is gopal

<gopal> for some reason mic is not working, I can hear you

<bhill2> (gopal - lots of noise from your line)

<gopal> I'll dial out and try again

<bhill2> klee, care to introduce yourself?

<bhill2> haven't seen you here before?

<klee> I've been on the last couple calls?

<bhill2> apologies

<klee> I'm Ken Lee, security engineer @ etsy

<klee> I usually don't say anything in these mtgs

<bhill2> :)

<bhill2> agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0013.html

scribenick ekr

<scribe> scribenick: ekr

Minutes approval

<bhill2> http://www.w3.org/2013/10/22-webappsec-minutes.html

Tracker

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

abarth: I haven't done anything

<abarth> ekr: :)

… push everything back to 12/12

abarth: my job is just to record what happens

<abarth> I know :)

<bhill2> glenn: if you are paying attn on irc, any thoughts / updates on https://www.w3.org/2011/webappsec/track/actions/151

<glenn> ... typing ...

<glenn> thanks for reminder, I will attend to this during this week; am presently in Philippines working on aid and recovery effort

<dveditz> did I lose the call?

<dveditz> :-) ok. saw typing but no sound

<bhill2> glenn: good luck, and good priorities

<bhill2> :)

blob, filesystem, etc. URIs in CSP

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0007.html

bhill2: latest comments were from dan… dan proposed not to add unsafe inline

… two ways of looking at constructed URI schemes. My proposal was to have these grouped under "self" where directive doesn't have unsafe inline or unsafe eval. When directive does have an unsafe inline then group under that.

… this is content that originates from same origin

abarth: a content injection vulnerability could allow data uri injection

bhill2: data and js should fall under unsafe inline. blob and filesystem fall under unsafe eval

dveditz: ...

bhill2: wherever the directive would have paid attention to an unsafe-* keyword we would follow that

abarth: maybe we should make these apply to all resources for futureproofing

… suppose in future we add unsafe-inline keyword to IMG SRC we would get weird behavior

… could head this off at the pass by adding support to all directives

bhill2: interesting....

<bhill2> that was deveditz

dveditz: my other proposal was that to use these, you would have to specifically whitelist the scheme

abarth: that proposal matches chrome
... my experience dealing with authors is that they have trouble whitelisting data uris

dveditz: from that perspective, brad's proposal is clearer

nobody really has strong opinions

[… lots of discussion about what's clearer...]

bhill2: does anyone have an opinion who isn't a browser author

… We have a clear question we can ask.

… if we have consensus that either is ok except for clarity; let's ask the list

dveditz: propose that we support them everywhere and see if people are confused?

<bhill2> ACTION abarth update CSP to make unsafe-inline, unsafe-eval universal constructs

<trackbot> Created ACTION-152 - Update csp to make unsafe-inline, unsafe-eval universal constructs [on Adam Barth - due 2013-11-26].

dveditz: need to go looka t FirefoxOS

<wseltzer> we can write a page on webplatform docs to explain

abarth: will write up the proposal from a few minutes ago and then reserach that this doesn't mess up our use case

handling workers, sharedworkers, etc.

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0008.html

bhill2: we originally said that workers inherited document csp policies

… the latest proposal after some discussion on the list is that workers should be governed by frame-src not script-src

abarth: two issues (1) what controls loading of worker and (2) while it's executing, what controls further loading

Sorry, got thrown out of room

calling back in

Back

<bhill2> dveditz: proposal to inherit policy of creating resource is what we do for srcdoc now

dveditz: only concern with frame src is what might break

<bhill2> dveditz: concern with switching to frame-src is what might break that depended on script-src

<bhill2> dveditz: makes policy of using headers delivered with worker script more sensible than with script-src

<bhill2> grobinson: for now we are implmenting 1.0 spec at Mozilla as we implement SharedWorkers

<bhill2> ... frame-src is confusing at first, but confusing

bhill2, should I take back over?

abarth(?): other option would be to create a worker src

<bhill2> bhill2: maybe add child-src as a synonym for frame-src for compat, applies to workers, frames, pop-ups

… other things coming related to this: html imports, service workers, ???

… current plan is that imports are like script-src subject to same policy of parent document

… service workers work a lot like shared workers, makes sense to have them be similar to shared workers

can whoever just spoke say again?

grobinson, can you re-state?

<bhill2> grobinson: other option is to create worker-src

thanks

dveditz: easy to create a new directive when we invent a new thing. if we invent something and them move it, we break a lot of poeple

abarth: more sympathetic to ahving the worker use the CSP policy that came with its resource than to change from script-src to frame-src

???: two different issues, what can workers do vs. what can a document create a worker from

dveditz: hearing strong agreement for using header policy to define policy for workers

… nonagreement about moving to frame-src

bhill2: not opposed to worker-src vs. frame-src. script-src seems inappropriate

… child-src as a synonym for frame-src would be ok

abarth: if the worker shared memory with the main document (if js were thread safe) would you feel differently

bhill2: yeah...

… but that's not how workers operate right?

abarth: half-way in between

dveditz: but can XHR requests back to self with credentials

bhill2: is any of that stuff that iframe origin can't do

abarth, dveditz: worker capabilities are a subset of iframe capabilities

bhill2: agreement that current specified behavior just doesn't work for shared workers

abarth: only point of disagreement is what directive controls loading of worker itselv

dveditz: right. script-src doesn't work but not clear if we want new directive or child-src

grobinson: frame-src seems like it has a confusing name but right semantics. would make sense to control with same directive (child-src)

abarth: webapps has a dom worker proposal

… specific proposal would be to have some way to have a trust boundary for dom worker

abarth: this points more towards child-src being good future proofing

grobinson: child-src seems better than worker-src

<bhill2> ACTION bhill2 propose more precise text for child-src directive idea

<trackbot> Created ACTION-153 - Propose more precise text for child-src directive idea [on Brad Hill - due 2013-11-26].

action bhill2 to propose more precise language for directives for shared worker

<trackbot> Created ACTION-154 - Propose more precise language for directives for shared worker [on Brad Hill - due 2013-11-26].

oop

<bhill2> ACTION dveditz update CSP to reflect that workers use policy resource is delivered with

<trackbot> Created ACTION-155 - Update csp to reflect that workers use policy resource is delivered with [on Daniel Veditz - due 2013-11-26].

dveditz: currently the spec says that src-doc chouls inherit policy parent but don't talk about loading

s/chould/should/

UISecurity and seamless iframes

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0105.html

bhill2: [summarizes mailing list]

<bhill2> gmaone, can you summarize your understanding of David Huang's mail?

bhill2: browsers will composite seamless iframes together....

gmaone: protection needs to be applied if any ancestors are from another origin

… same site can composite whatever it wants

… import input protection when composited with foreign data

gmaone, thanks

bhill2: no action needed

plugin-src none and resource loading

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0001.html

grobinson: need to rely on plugin to enforce CSP

… in the case of object-src none we should refuse to load any plugins

dveditz: even with non-problematic plugins, we can at best control initial load

… but Java is a particularly hard case

bhill2: since we have two implementations that share this bug, should we add some extra text

abarth: one thing to keep in mind is that there are plugins which don't load resources.

… e.g., gears plugin

cory: non-url-based plugins use current resource

… so if self was set, that would work

abarth: one way to get this behavior would be to treat the plugin that had url of containing document for the initial load

???: for object-src none, don't load. For objects with no url, match against self

… from there the plugin can load what it likes

abarth: one way to interpret it is that the plugin can either determine what the plugin will do or it can't. if it can, use that url, otherwise use document url

<bhill2> ACTION abarth clarify plugin-src behavior: if able to determine resource, self or none

<trackbot> Created ACTION-156 - Clarify plugin-src behavior: if able to determine resource, self or none [on Adam Barth - due 2013-11-26].

<wseltzer> new charter: http://www.w3.org/2013/07/webappsec-charter.html

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-03-10 21:39:32 $