WebAppSec WG Teleconference, 04-June-2013 -- 04 Jun 2013

<bhill2> Minutes from last month's call: http://www.w3.org/2013/05/07-webappsec-minutes.html

<bhill2> RESOLVED: minutes approved

<bhill2> scribenick: dvetitz

<bhill2> scribe: Dan Veditz

<dveditz> scribenick: dveditz

minutes from last time (5/7/2013) is approved

bhill2: last minute agenda wrangling, abarth would like to discuss script nonce maturity
...: if we have any more time we can add discussing the UI safety issues Peleus brought up on the list

tracker

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner
...: topic tracker opened
... abarth had an issue to check with accessibility team

abarth: not done
... thought I had done content-types for reports, I'll do that right now

<ekr> bhill: do you want me to run the tracker?

bhill2: assume dveditz has not done his since he just got editor access [dveditz; yup]
... action 130, referrer control policy -- is that in the spec?
... don't see it, going to assume all the open actions are going to remain open

<bhill2> https://www.w3.org/2011/webappsec/track/issues/raised

bhill2: raised issues
... 7 at this point
... issue 44, can table that for now until we discuss how script-hash interacts with script nonce
... wait on issue 47, dveditz's addition of spec language for meta header

<ekr> willdo

bhill2: ekr can you close issue 48 since we have spec text to address it?
... issue 49, add http response code to report. anyone want to take that?

<bhill2> https://www.w3.org/2011/webappsec/track/issues/49

bhill2: neil had asked if it would be possible to add this

abarth: you can give that to me

<bhill2> ACTION abarth to add HTTP response code to reports in CSP 1.1

<trackbot> Created ACTION-139 - Add HTTP response code to reports in CSP 1.1 [on Adam Barth - due 2013-06-11].

<ekr> dan: you can make actions the way bhill just did

abarth: also a bug filed into the tracker about specifying best practices, you can give that to me as well

<bhill2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22256

<bhill2> ACTION abarth to add text addressing https://www.w3.org/Bugs/Public/show_bug.cgi?id=22256

<trackbot> Created ACTION-140 - Add text addressing https://www.w3.org/Bugs/Public/show_bug.cgi?id=22256 [on Adam Barth - due 2013-06-11].

bhill2: issue 51 How to handle externally defined <element> with <link rel=import> -- is it worth defining an "import-src"?
... or treat custom elements as a constellation where yiou have to specify script-src, style-src, etc

abarth: i think we should use script-src, if we use something new people who are trying to control scripts could be bypassed by this new thing
... I'd like to make it possible for the spec that defines this thing to specify which policy it falls under
... I want to get away from use defining everything under the sun but allow other specifications to reference how they are covered by CSP

bhill2: last two rae issues for me and I have not looked into those

Script API to CSP

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013May/0000.html http://infrequently.org/2013/05/use-case-zero/

<bhill2> http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/

bhill2: next item is looking at the security policy script interface based on the responses on the mailing list, discussion involving alex russel and edward vela

abarth: I think there are 2 parts of this -- some object that corresponds to the parsed representation of the policy string, and .... ?
... the original api we had was a way to query an effective policy, the second one, but didn't provide a string representation of the parsed policy
... I think if we separate those we can address alex's issues

bhill2: anyone else have any comments?
... I think we still have an open question of how to give an advanced user fined-grained control and I'd like to continue to explore that beyond CSP 1.1

abarth: I think we can talk when I make my proposal, how to incrementally grow the capabilities

bhill2: next topic, security model for SVG components
... haven't had the time to really grok what this is about -- seems like it would take a deep understanding of the issues to address
... we don't seem to have the right people involved on the call, does anyone here feel they could summarize?

abarth: issue is that some oc the SVG mechanisms are mediated by CSS and some aren't. what should the policy be for these loads?
... some of them want it to be simple like image loads, and some thought it should use CORS because of possible information leaks

ekr: it was hard to tell if there was any real risk here

abarth: even if you make things public with CORS it's better than not using CORS because it divorces cookies from the request and makes it less likely a server will leak personal/private data

ekr: I promised to loop bz in because he's not on the call.... do we have a clear statement of position we can give him?

abarth: I'm happy to write it. I'd write it "this is my opinion" not the sense of the call thouigh

bhill2: I like that statement of CORS... should it apply to link rel=import too?

abarth: yes it should

bhill2: ... this is general advice not just how it applies to CSP, that would be a good thing to have a discussion on

broadening default-src semantics

bhill2: moving on. broadening default-src semantics

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

abarth: summary-- Yehuda Katz cornered me that we shouldn't have to update the CSP spec every time the "web" spec gets updated
... he was focusing on default-src, but really it was about writing the spec more generally
... there might be some loads that are not specifically controllable that would fall back to default-src

bhill2: anyone object to that

<bhill2> ACTION abarth to update CSP 1.1 default-scr language to be more general, including coverage of areas not specified by other directives

<trackbot> Created ACTION-141 - Update CSP 1.1 default-scr language to be more general, including coverage of areas not specified by other directives [on Adam Barth - due 2013-06-11].

nonce-source

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

bhill2: last topic, nonce-source
... email says currently nonce is only defined for script-src and style-src -- should it be more general (any directive) or does it only make sense for those two directives

dveditz: I'm inclinced to limit it to script and style, which are the ones with unsafe-inline

bhill2: should we say it can't be used in default-src ?

abarth: the way it's in the spec right now it's very much like "unsafe-inline" -- you can put it in default-src currently, but it only take effect in the directives that understand it
... nonce is currently written the sme way

bhill2: we had this discussion about data: and things as well, are those useful to think about in these terms?

abarth: the interesting one there is data: because if you whitelist data: you're sort of whitelisting script injection so there nonce might make sense
... the people I talk to who want to use nonce it's overwhelmingly for inline scripts which can't be removed for various reasons like performance
... haven't heard anyone complain about not being able to use data: uris

bhill2: ok, we'll limit it to script and style for now since that's been the focus and people can bring up broadening it later if they like

abarth: I've been talking to a number of people considering CSP who have gotten somewhat through their implementation
... they're running up agains the inline-script problem -- where there are a couple they can't remove
... they got really interested in nonce-src
... how far are we from candidate recommendation, maybe for all of CSP 1.1 or something with "strong consensus"
... how would the working group feel if chrome implemented nonce-src ahead of the standards

bhill2: my feel as the chair is that we're getting close to feature complete on 1.1, maybe a few things we've discussed that aren't in there
... referrer tag, return status code
... to move beyond (??) we have to have a reasonable demonstration that we have compatible implementations, not a complete test suite necessarily, but can't mark 2/3 incomplete or unready

abarth: the biggest risk you didn't mention was the script interface
... can the WG push forward with what we have and put the script interface into a later version of CSP?

bhill2: we could do that, but the biggest hurdle is interoperable implementations
... since mozilla is the only other one with a CSP 1.0 implementation this will largely depend on when Mozilla can get CSP 1.1 features implemented

tanvi: our CSP 1.0 implementation will be in Firefox 23

bhill2: congratulations
... do you know when you're going to have CSP 1.1 stuff implemented?

tanvi: I don't know the timeline

bhill2: you (abarth) suggested moving nonce out from behind the flags.... if we have two implementations of that specific feature and it seems solid and not likely to change then that seems possible
... right now you have to turn the features on using command-line flags. nonce is so useful for implementers that chrome would like to enable it without having to do that

tanvi: I don't know how long it will take for us to get to that

abarth: we're going to drop support for the prefixed header, they're not healthy for the web. We're adding new stuff to the official header, but only if you specify a runtime flag
... I'd like to get people using CSP, and the last blocker for some of these groups is support for nonce-src. I don't want to end-run the W3C process, but I'd like to get this feature out there

bhill2: if you want to ride the bleeding edge in your product there are ways to do that that are less risky
... joel weinberger has volunteered testcases for that feraturte that will help ensure interoperability
... that will help answer whether this is stable and ready for use. that's better than fragmenting the spec into more subversions to get this feature rolling
... I'll end with a plug for testing: anyone out there a github wizard and can help us move the testcases from mercurial to github?
... there's currently a one month lag between me checking in a testcase and it showing up in public
... have heard that github will make this process better but i'm a total github noob

ekr: what's he wanting to do, import the history from mercurial?

bhill2: there's some particular way to set up github for that kind of access

ekr: wendy can you help us find out what the requirements for that would be? I don't want to import it all and find out it has to have special directory names or files

wseltzer: I can do that

ekr: does w3c have a github account? if not I can do it under mozilla. I don't want to do it under my name in case I get hit by a bus and then no one can access it

wseltzer: yes, we do but I don't know the process yet

bhill2: I want to host a "test the web forward" here in seattle. would like someone to do that in the bay area too

<wseltzer> ACTION wseltzer to email bhill, ekr, and tobie re github setup

<trackbot> Created ACTION-142 - Email bhill, ekr, and tobie re github setup [on Wendy Seltzer - due 2013-06-11].

bhill2: have script-src completely covered, but there's more to do

thanks.

- DRAFT -

WebAppSec WG Teleconference, 04-June-2013

04 Jun 2013

Attendees

Contents

tracker

Script API to CSP

broadening default-src semantics

nonce-source

Summary of Action Items

Scribe.perl diagnostic output