[![W3C][1]][2] # WebAppSec F2F ## 02 May 2012 See also: [IRC log][3] ## Attendees Present Adam_Barth, Brad_Hill, Daniel_Veditz, Eric_Rescorla, Giorgio_Maone, Gopal_Raghavan, Jacob_Rossi, Jeff_Hodges, Peleus_Uhley, Philippe_De_Ryck, Tanvi_Vyas, Travis_Leithead Regrets Chair Brad_Hill, Eric_Rescorla Scribe ekr ## Contents * [Topics][4] 1. [CSP 1.0 outstanding issues][5] 2. [ISSUE #8][6] 3. [should we have meta in 1.0 or not?][7] 4. [CSP access API?][8] 5. [frame-ancestor or frame-options][9] 6. [script-hash][10] 7. [no-user-js][11] 8. [restrict script to sources with specific content types][12] 9. [form-action][13] 10. [plugin-types][14] 11. [jsonp with padding][15] * [Summary of Action Items][16] * * * scribenick: ekr bhill: start installing your vms bridge is up who just joined? sorry to yank the rug, but we are headed next door to webapps to discuss last call comments for CORS will be back at 10:15, and I will leave the bridge open jeffh: the current spec is baffling if you're not a browser implementer ... I told Anne that already [discussion about how to pass this information back.] Scribing will be happening in webapps for now talking about CORS joint with webapps, guess we're in their room for that ACTION bhill to integrate jeffh comments int sec considerations in CORS Created ACTION-58 - Integrate jeffh comments int sec considerations in CORS [on Brad Hill - due 2012-05-09]. It seems the conference bridge's audio has stopped. jrossi: we had problems with feedback Ah, I see. I'm fine with just watching the IRC if you guys take good notes. :-) ### CSP 1.0 outstanding issues [WebAppSec Open Issues][17] abarth: I thought we resolved issue 8 a while ago issue 35: dveditz: A lot of proxies will mangle this anyway bhill: this came out of IETF dveditz: Mozilla's solution was to have an intersecting policy ... I don't think we can say don't combine this abarth: if there is a comma, there is an error processing case. dveditz: the proxies will just merge them anyway. abarth: how shall we handle the error of the server sending multiple errors and the proxy combining them. dveditz: I can see how this happens. [... discussion...] Abarth and Dveditz suggest that comma be illegal. abarth: how shall we handle it? dveditz: I would prefer an intersecting policy ekr: why not treat it as an illegal policy? abarth: what should be the behavior if you get a policy without any of the known directives? dveditz: shouldn't that be default source = none tanvi: why not take the most restrictive? dveditz: +1 abarth: it's not clear which one it is? ... and now you're into intersecting policies bhill: this text I sent is designed to cover this. abarth: turns out that comma is forbidden but we recover ... I suggest that with comma we set the policy to some invalid policy. bhill: like default src = none abarth: yeah, and I would probably log in the error console. ekr: how should we handle other cases where the policy is invalid, abarth: e.g., directive name == backspace or dollar sign ... currently it gets parsed as a directive name. It's illegal but causes no failure. ekr: the general philosophy is that if you can make sense of it, do it? abarth: it's semicolon delimited, so if I don't understand the thing in between the semicolons, then I ignore it. ekr: Do we want to revisit the design decisions (a) no intersection and (b) non-restrictive default policies. dveditz: I wasn't paying that much attention before, but I would still prefer intersection bhill: the argument last time was that intersection was hard dveditz: yah, it's not perfect. It does tend towards breaking the page. bhill: what about combining only policies of type src list abarth: most important thing is for it to be extensible. ... want to have something good I can take back to websec ... can't merge on a directive by directive basis ... I see policy combination as really complicated and benefit is not that large dveditz: what is the proposed handling if we get a comma? abarth: the thought is that since it is syntactically invalid, the policy is now default source none and print something to the debug console. dveditz: seems like ignoring everything after the comma is consistent with first policy wins, but maybe we don't know which order the proxies assemble the headers in ekr: right, but this means that a bad policy is ultra-dangerous as opposed to breaking everything bhill: philosophy has always been that this is a safety belt abarth: we find that when people deploy CSP, they find that there aren't a lot of violations and so they aren't sure policy is running. ... I would like to have some way to ask it. bhill: what if there is some proxy elsewhere. ekr: what if there are multiple proxies? This makes it very dangerous... abarth: do proxies like this really exist? tanvi: so if we have two headers right now we do nothing? ... the other thing about intersecting policies is if we have meta tag and policy URI we might have to deal with this. abarth: meta tag used to be trumped by header ... something else I want to talk about for 1.1--there is a use case to modify policy at run time. It's delicate to do that in a good way bhill: how he handle combination logic, then this impacts how things behave in the future ... in the future, we are going to have proxies which do CSP injection, then this won't work with any future meta tag abarth: maybe say you must only send one policy and then if you receive two you fail in some obnoxious way. ... and if we add a new way to get policies we specify a combination mechanism then. bhill: this still leaves it open how people who do want to do policy injection. We should give them some advice. abarth: those people are more able to adapt. bhill: well, WAFs don't adapt much ekr: well, the reason we didn't do it was because it was hard. If these guys want to try it, then good for them, but we don't have to abarth: my current proposal {two policies, comma in header} --> enforce default src=none bhill: so no meta tag? ... it's on the agenda later ... is now a good time to discuss the meta tag for 1.0? abarth: I think we should talk about that in 1.1 ... it's related to other things in 1.1 bhill: the question of meta in 1.0 has to be on our agenda. shall we revisit it now because it may impact the combination logic. dveditz: how so? ... other headers with meta tags have had the header override the meta tag tanvi: what if we forbid duplication now and then specify merging in 1.1? travis: historically don't meta tags trump headers dveditz: typically the other way around travis: from a security perspective, that seems ok, but practically don't you want the opposite abarth: that's just the way the web is even if it's backwards travis: well, in some cases IE does that dveditz: it's a matter of who wants what -- web page authors versus site operators travis: personally I want to not see meta tags in 1.0 so we finish [http://www.w3.org/2011/webappsec/track/issues/open][17] [ taking a break till 11:30 ] [http://www.w3.org/TR/CSP/][18] [ we are back ] ### ISSUE #8 issue-8? ISSUE-8 -- Identify proper behavior for html added via plubins / object tag -- open [http://www.w3.org/2011/webappsec/track/issues/8][19] balance between the user's preferences and the site authors dveditz: both user and site operator are concerned about attacks and the user can always override the site's preferences as a technical matter abarth: my sense is that we agree about principles, and the details are a matter of the implementations which vary anyway dveditz: if the UA lets the user add extensions, we are still respecting CSP in a reasonable way. abarth: I view the current text as sort of aspirational. ... as an example, in Chrome a content script can load images from its own extension package regardless of CSP ekr: I propose we mark this closed and move onto meta and sandbox bhill: we have requests from a bunch of people to restore the meta tag ... my summary is that there are a lot of site admins who can't set headers but would like to use CSP ... so this is worth the risk abarth: my sense is that this interacts with CSP 1.1 proposed features such as the ability to query policy dveditz: I'm much more concerned with a DOM API to set policy than I am about a meta tag abarth: is there anyone who thinks this should be in 1.0? tanvi: we'll need to discuss anyway dveditz: one concern about injectable policy via meta is leak via reporting. maybe add same origin requirement for reports in meta ... would also like to restrict meta to HEAD abarth: how would you feel if we restricted meta tag to HEAD. How would you feel if someone injected it later? dveditz: I think that's cheating abarth: so only if it's in head and available at the start. ... example is gmail dveditz: what if I had a meta tag that said "allow deferred DOM API CSP injection later" bhill: use cases is restrictive server environments ... maybe these use cases can't meaningfully consume reports anyway dveditz: might be willing to stick to simplest use cases tanvi: what would requirements be: meta tag == no report, meta tag must be in HEAD, must be no header abarth: + must be inserted by parser [discussion about what 'inserted by parser'] [discussion about what we are trying to achieve by restricting this?] bhill: if you can inject script then it's game over ... I'm not sure there is any reason to restrict it from being added by script dveditz: the spec should just recommend that it go early. bhill: if you screw up before the meta, you're on your own dveditz: want same origin reports tanvi: don't want same origin reports--encourage people to use header instead of meta tag bhill: if you're only able to run static comment anyway ... how many scenarios is this relevant for? tanvi: the only places this is really going to happen are corp environments and those people should go talk to their admins abarth: my notes say Bringing back the tag, Must be in the Header trumps tag First tags wins report-uri doesn’t work Guidance that delaying the header isn’t wise dveditz: meta must come through parser. bhill: what's the security benefit here? All you can do is inject a new policy? abarth: my preference is to not care how the data is inserted. ... suggestion is to use no insertion after ready state. ekr: what's the security reason for this? bhill: It seems like an implementation simplification ekr: ok ### should we have meta in 1.0 or not? nobody in room wants it in 1.0. people on list have requested it dveditz: we are probably closer to meta than sandbox bhill: if all implementers agree they don't want to do meta in 1.0 ... then it doesn't need to be in 1.0 spec. by comparison, sandbox has some implementation. but no implementations, then meta loses... tanvi: just because it's not in 1.0 doesn't mean people don't do it abarth: my plan is to have it with a prefix **RESOLUTION: meta will be in 1.1 due to lack of implementer support for having it in 1.0. we will attempt to specify it early in 1.1.** what happened with onload vs. inserted by the parser. i believe we decided the policy should be set onload? or did we decide not to specify that bhill: anyone want to revisit consensus on sandbox. We had interest from implementers on doing it, and we're going to re-check implementation status at CR...? abarth was going to use wording along the lines of "before document readystate" does Microsoft have the full csp 1.0 implemented? abarth: can we have a feature that we may drop if we do not have two implementations? philippe: you need to mark it as "at risk" ... if you mark it as at risk, you don't need to recycle to LCWD if you drop it. proposed resolution: we mark this at risk and then if we don't have two implementations, it gets dropped. bhill: can MS live with having this in 1.1? travis: main concern is that it not just look like a MS feature bhill: jrossi is willing to specify this abarth: we outsource parsing to HTML5 dveditz: what if HTML5 changes? abarth: they need to retain backcompat bhill: propose that we punt this to 1.1 since MS won't have a complete implementation anyway. Then we can move to LC soon. ... will raise on list **ACTION:** abarth to create 1.1 impl by end of week [recorded in [http://www.w3.org/2012/05/02-webappsec-minutes.html#action01][20]] Created ACTION-59 - Create 1.1 impl by end of week [on Adam Barth - due 2012-05-09]. **RESOLUTION: we will punt Sandbox to 1.1 pending approval on list.** dveditz: what about future compatibility for more specific policies, e.g., src lists that specify directories ... if we come up with a compatible syntax now. abarth: proposal, allow full URLs but truncate to the origin. script-src [http://example.com][21] [http://foo.com/bar/qux][22] dveditz: if someone types in [https://www.google.com/][23] that is ignored because of trailing slash script-src 'self' [http://dev1.addons.phx1.Mozilla.com][24] [https ://addons-dev-cdn.allizom.org/][25] proposal: allow urls, and truncate them to the origin. this ends up whitelisting an entire origin, when perhaps you just want to whitelist a path. so perhaps we should version cps? *csp? script-src and script-src-path we could add a version to the specified policy. if the version =1.1, then allow paths in sources. if the version is 1.0, then ignore sources with paths. choices appear to be a) version CSP header, b) duplicate directives in the future, c) degradation of hosts with paths a) means two headers always. CSP2 clients need to look for both headers, sites may just leave CSP1 clients insecure b) pretty much the same on a directive level -- either duplicate, or leave CSP1.0 clients as insecure as non-CSP clients **ACTION:** dveditz to write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [recorded in [http://www.w3.org/2012/05/02-webappsec- minutes.html#action02][26]] Created ACTION-60 - Write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [on Daniel Veditz - due 2012-05-09]. dveditz: people also want to be able to specify plugins by media type. E.g., flash but no java **ACTION:** abarth to merge bhill's policy combination text into the CSP document [recorded in [http://www.w3.org/2012/05/02-webappsec- minutes.html#action03][27]] Created ACTION-61 - Merge bhill's policy combination text into the CSP document [on Adam Barth - due 2012-05-09]. [http://www.w3.org/Security/wiki/Content_Security_Policy][28] [https://mikewest.org/2012/05/content-security-policy-feature- detection][29] are you people talking about clickjacking? I heard "...ckjacking" but it's all silence and some word here and here on the SIP bridge :( talking about CSP 1.1 proposed features right now I will try to turn up the microphone i believe the anti-clickjacking discussion is tomorrow [http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0016.html][30] ### CSP access API? [http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version _1.1][31] peleus: what happens if you try to eval() with CSP abarth: throw a security exception ... why is this useful? Avoid reporting errors for feature tests ### frame-ancestor or frame-options abarth: maybe we can get this back in jeffh: now is a good time to participate in websec abarth: maybe it should be possible for IETF documents to specify CSP directives i have a couple of potential additions I'd like to bring up bhill: two ways to look at the world. (1). Anything new is CSP 1.1. (2) anything that changes how things work is CSP 1.1 and anything else is just new directives tanvi: you have access to the wiki? ... I just added some stuff sure, I'll do that added ### script-hash peleus: this seem like it's a maintainability issue dveditz: this starts to get pretty long ... what about policy-uri? this way you could imbed third party script that you trust (ex: Facebook like widget) and know that if Facebook's servers gets compromised, the hash won't match and your page won't be vulnerable (regarding script-hash) script-src [http://google-analytics.com][32] [###]. so only [http://www.google-analytics.com/ga.jsworks][33], and nothing else from google-analytics works. ### no-user-js tanvi: idea to prevent against self-xss. ... no longer allow js: in address bar ... but you could still get people to do "open" ... idea would be to require special to activate the web console in these cases (where policy is provided) dveditz: not sure how serious this is.... it is for fb and twitter ... really only applies to a subset of sites. ekr: this is a social engineering question dveditz: interesting idea but not sure I want to jump right in on it. ### restrict script to sources with specific content types peleus: this causes a lot of problems tanvi: idea here is to restrict scripts to a specific set of content-types abarth: historically, this has been something people have ignored, so there will be a lot of collateral damage ... having it be opt-in ekr: you could have the white-list in the directive abarth: better to have it be binary ### form-action bhill: HTML5 makes form tag injection easier abarth: this seems like it would help defend against that and be within the scope of the kind of stuff we have done ### plugin-types dveditz: syntax seems complicated ... argue about it later abarth: seamless with parent ... iframe can resized like a div. ... right now it's single origin ... might be nice to have a directive that allows it even without same origin ekr: this seems like it's conceptually new since it's not a restriction travis: IE already allows iframe resizing abarth: this is a little different ... put it here so the group is aware of it. not sure where it goes ### jsonp with padding bhill: a lot of people want to have safe JSONP ... jsonp-src : a list of domains ... jsonp-sink: a list of safe function names ... idea is that you could apply it to existing legacy code ... two objections from lcamtuf: (1) this doesn't solve jsonp being interpreted as scripts (2) it may not actually permit a lot of valid jsonp ekr: this seems like a good idea, but not sure it can be made to work abarth: I had one more... meta-referrer ... finally, more granular origin list tanvi: who has implemented meta tag for referer? dveditz: should this be a meta tag? separate or in csp? abarth: this feels like a policy thing dveditz: I agree with that for things that are specified as headers.... bhill: distinction between proposals that rev the spec and proposals that add new directives ... what are examples of revving the spec? policy-uri, more granular origins [ abarth is currently modifying the page to divide between experimental and proposals for 1.1 ] abarth: excited about form action ... plugin types might be a good one bhill: negative plugin types? [https://trac.webkit.org/browser/trunk/LayoutTests/http/tests/securit y/contentSecurityPolicy][34] Hope your VM is up please switch to branch testJam and add your tests on this branch ## Summary of Action Items **[NEW]** **ACTION:** abarth to create 1.1 impl by end of week [recorded in [http://www.w3.org/2012/05/02-webappsec-minutes.html#action01][20]] **[NEW]** **ACTION:** abarth to merge bhill's policy combination text into the CSP document [recorded in [http://www.w3.org/2012/05/02-webappsec- minutes.html#action03][27]] **[NEW]** **ACTION:** dveditz to write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [recorded in [http://www.w3.org/2012/05/02-webappsec- minutes.html#action02][26]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][35] version 1.135 ([CVS log][36]) $Date: 2009-03-02 03:52:20 $ [1]: http://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: http://www.w3.org/2012/05/02-webappsec-irc [4]: #agenda [5]: #item01 [6]: #item02 [7]: #item03 [8]: #item04 [9]: #item05 [10]: #item06 [11]: #item07 [12]: #item08 [13]: #item09 [14]: #item10 [15]: #item11 [16]: #ActionSummary [17]: http://www.w3.org/2011/webappsec/track/issues/open [18]: http://www.w3.org/TR/CSP/ [19]: http://www.w3.org/2011/webappsec/track/issues/8 [20]: http://www.w3.org/2012/05/02-webappsec-minutes.html#action01 [21]: http://example.com [22]: http://foo.com/bar/qux [23]: https://www.google.com/ [24]: http://dev1.addons.phx1.Mozilla.com [25]: https://addons-dev-cdn.allizom.org/ [26]: http://www.w3.org/2012/05/02-webappsec-minutes.html#action02 [27]: http://www.w3.org/2012/05/02-webappsec-minutes.html#action03 [28]: http://www.w3.org/Security/wiki/Content_Security_Policy [29]: https://mikewest.org/2012/05/content-security-policy-feature- detection [30]: http://lists.w3.org/Archives/Public/public- webappsec/2011Dec/0016.html [31]: http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for _Version_1.1 [32]: http://google-analytics.com [33]: http://www.google-analytics.com/ga.jsworks [34]: https://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security /contentSecurityPolicy [35]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [36]: http://dev.w3.org/cvsweb/2002/scribe/