See also: IRC log
<scribe> scribenick: ekr
bhill: start installing your vms
<bhill> bridge is up
<bhill> who just joined?
<bhill> sorry to yank the rug, but we are headed next door to webapps to discuss last call comments for CORS
<bhill> 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
<dveditz> talking about CORS
<dveditz> joint with webapps, guess we're in their room for that
<bhill> ACTION bhill to integrate jeffh comments int sec considerations in CORS
<trackbot> Created ACTION-58 - Integrate jeffh comments int sec considerations in CORS [on Brad Hill - due 2012-05-09].
<jrossi> It seems the conference bridge's audio has stopped.
<abarth> jrossi: we had problems with feedback
<jrossi> Ah, I see. I'm fine with just watching the IRC if you guys take good notes. :-)
<abarth> WebAppSec Open Issues
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
<abarth> http://www.w3.org/2011/webappsec/track/issues/open
[ taking a break till 11:30 ]
<tanvi> http://www.w3.org/TR/CSP/
[ we are back ]
issue-8?
<trackbot> ISSUE-8 -- Identify proper behavior for html added via plubins / object tag -- open
<trackbot> http://www.w3.org/2011/webappsec/track/issues/8
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
<abarth> Bringing back the <meta> tag,
<abarth> Must be in the <head>
<abarth> Header trumps <meta> tag
<abarth> First <meta> tags wins
<abarth> report-uri doesn’t work
<abarth> 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
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.
<tanvi> 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...?
<dveditz> abarth was going to use wording along the lines of "before document readystate"
<tanvi> 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
<scribe> ACTION: abarth to create 1.1 impl by end of week [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action01]
<trackbot> 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.
<abarth> script-src http://example.com http://foo.com/bar/qux
<bhill> dveditz: if someone types in https://www.google.com/ that is ignored because of trailing slash
<tanvi> script-src 'self' http://dev1.addons.phx1.Mozilla.com https://addons-dev-cdn.allizom.org/
<tanvi> proposal: allow urls, and truncate them to the origin.
<tanvi> this ends up whitelisting an entire origin, when perhaps you just want to whitelist a path.
<tanvi> so perhaps we should version cps?
<tanvi> *csp?
<tanvi> script-src and script-src-path
<tanvi> 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.
<dveditz> choices appear to be a) version CSP header, b) duplicate directives in the future, c) degradation of hosts with paths
<dveditz> a) means two headers always. CSP2 clients need to look for both headers, sites may just leave CSP1 clients insecure
<dveditz> b) pretty much the same on a directive level -- either duplicate, or leave CSP1.0 clients as insecure as non-CSP clients
<scribe> 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]
<trackbot> 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
<scribe> 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]
<trackbot> Created ACTION-61 - Merge bhill's policy combination text into the CSP document [on Adam Barth - due 2012-05-09].
<abarth> http://www.w3.org/Security/wiki/Content_Security_Policy
<abarth> https://mikewest.org/2012/05/content-security-policy-feature-detection
<gioma1> are you people talking about clickjacking? I heard "...ckjacking" but it's all silence and some word here and here on the SIP bridge :(
<bhill> talking about CSP 1.1 proposed features right now
<bhill> I will try to turn up the microphone
<tanvi> i believe the anti-clickjacking discussion is tomorrow
http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0016.html
http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1
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
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
<tanvi> 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
<tanvi> sure, I'll do that
<tanvi> added
peleus: this seem like it's a maintainability issue
dveditz: this starts to get pretty long
... what about policy-uri?
<tanvi> 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
<tanvi> (regarding script-hash)
<tanvi> script-src http://google-analytics.com [###]. so only http://www.google-analytics.com/ga.jsworks, and nothing else from google-analytics works.
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.
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
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
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
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?
<abarth> https://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/contentSecurityPolicy
<gopal> Hope your VM is up
<gopal> please switch to branch testJam
<gopal> and add your tests on this branch