WebAppSec F2F

02 May 2012

See also: IRC log


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
Brad_Hill, Eric_Rescorla


<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. :-)

CSP 1.0 outstanding issues

<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 ]



<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

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.

<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


CSP access API?


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

<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.

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


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

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?

<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

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]
[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]
[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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $