IRC log of webappsec on 2012-05-02

Timestamps are in UTC.

15:54:15 [RRSAgent]
RRSAgent has joined #webappsec
15:54:15 [RRSAgent]
logging to http://www.w3.org/2012/05/02-webappsec-irc
15:54:27 [bhill2]
zakim, this will be 92794
15:54:27 [Zakim]
I do not see a conference matching that name scheduled within the next hour, bhill2
15:54:32 [bhill2]
rrsagent, begin
15:54:46 [bhill2]
hmm, looks like we may not have a reservation anyway
15:59:12 [gioma1]
bhill2: does it mean the bridge is not available?
15:59:32 [bhill2]
let me try again
15:59:39 [bhill2]
zakim, this is 92974
15:59:39 [Zakim]
sorry, bhill2, I do not see a conference named '92974' in progress or scheduled at this time
15:59:53 [bhill2]
zakim this is 92794
16:00:00 [bhill2]
zakim, this is 92794
16:00:17 [Zakim]
sorry, bhill2, I do not see a conference named '92794' in progress or scheduled at this time
16:02:20 [bhill2]
sorry folks, looks like the staff didn't get the reservation set up in time
16:02:23 [bhill2]
bridge is unavailable
16:06:22 [JeffH]
JeffH has joined #webappsec
16:09:17 [bhill2]
getting a slow start today, waiting for folks to arrive in person
16:09:46 [bhill2]
I have put in a request for the phone bridge for tomorrow, Philippe is following up. Possibility of getting it enabled later today.
16:17:18 [plh]
plh has joined #webappsec
16:26:02 [bhill2]
phone bridge should be available within the 1/2 hour
16:29:14 [ekr]
ekr has joined #webappsec
16:30:14 [ekr]
scribenick: ekr
16:30:16 [abarth]
abarth has joined #webappsec
16:30:39 [ekr]
bhill2: start installing your vms
16:30:54 [plh]
zakim, list conference
16:30:54 [Zakim]
I don't understand 'list conference', plh
16:31:00 [plh]
zakim, list conferences
16:31:00 [Zakim]
I see T&S_Track(dnt)12:00PM, XML_EXI()12:30PM, Team_(wf)16:00Z, Style_CSS FP()12:00PM, SW_RDB2RDF(TR)12:00PM, SW_RDFWG()11:00AM active
16:31:04 [Zakim]
also scheduled at this time are IA_WebApps(F2F)9:00AM, WAI_PF()12:00PM, VB_VBWG(SCXML)12:00PM, T&S_EGOV(UseWebTech)12:00PM, SEC_WASWG()12:00PM
16:31:18 [plh]
zakim, this is waswg
16:31:18 [Zakim]
plh, I see SEC_WASWG()12:00PM in the schedule but not yet started. Perhaps you mean "this will be waswg".
16:31:23 [plh]
zakim, this will be waswg
16:31:23 [Zakim]
ok, plh; I see SEC_WASWG()12:00PM scheduled to start 31 minutes ago
16:32:57 [Zakim]
SEC_WASWG()12:00PM has now started
16:33:04 [Zakim]
+ +1.650.693.aaaa
16:33:27 [bhill2]
bridge is up
16:34:17 [Zakim]
+??P15
16:34:19 [bhill2]
zakim aaaa is bhill2
16:34:35 [bhill2]
who just joined?
16:35:43 [bhill2]
sorry to yank the rug, but we are headed next door to webapps to discuss last call comments for CORS
16:35:54 [bhill2]
will be back at 10:15, and I will leave the bridge open
16:36:21 [Zakim]
-??P15
16:38:35 [ekr]
jeffh: the current spec is baffling if you're not a browser implementor
16:39:18 [ekr]
... I told Anne that already
16:39:36 [plh]
q+
16:40:25 [plh]
oops
16:40:26 [plh]
q-
16:40:47 [ekr]
[discussion about how to pass this information back.]
16:44:19 [ekr]
ekr has joined #webappsec
16:47:24 [ekr]
ekr has joined #webappsec
16:47:40 [ekr]
Scribing will be happening in webapps for now
16:48:44 [Zakim]
+ +1.858.485.aabb
16:53:17 [Zakim]
- +1.858.485.aabb
16:55:42 [dveditz]
dveditz has joined #webappsec
16:56:50 [gopal]
gopal has joined #webappsec
16:57:11 [gopal]
which room are you meeting in
16:57:47 [dveditz]
gopal: the one with all the people in it
16:57:56 [dveditz]
(didn't catch the name on the way in)
16:58:11 [gopal]
what happened to saturn
16:58:12 [dveditz]
--not-- the one with the sign outside saying webapp security
16:58:20 [gopal]
ok
16:58:23 [dveditz]
talking about CORS
16:58:33 [dveditz]
joint with webapps, guess we're in their room for that
16:58:33 [gopal]
will be there
17:12:45 [jrossi]
jrossi has joined #webappsec
17:17:42 [ekr]
ekr has joined #webappsec
17:21:54 [tanvi]
tanvi has joined #webappsec
17:21:59 [Zakim]
+[Microsoft]
17:28:32 [abarth]
abarth has joined #webappsec
17:34:46 [bhill2]
zakim, who is here
17:34:46 [Zakim]
bhill2, you need to end that query with '?'
17:34:50 [bhill2]
zakim, who is here?
17:34:50 [Zakim]
On the phone I see +1.650.693.aaaa, [Microsoft]
17:34:51 [Zakim]
On IRC I see abarth, tanvi, jrossi, gopal, dveditz, plh, JeffH, RRSAgent, Zakim, bhill2, anne, gioma1, trackbot, bhill22, caribou
17:36:40 [ekr]
ekr has joined #webappsec
17:36:48 [bhill2]
ACTION to bhill2 to integrate jeffh comments into sec considerations in CORS
17:36:48 [trackbot]
Sorry, couldn't find user - to
17:37:01 [bhill2]
ACTIN bhill2 to integrate jeffh comments int sec considerations in CORS
17:37:11 [bhill2]
ACTION bhill2 to integrate jeffh comments int sec considerations in CORS
17:37:11 [trackbot]
Created ACTION-58 - Integrate jeffh comments int sec considerations in CORS [on Brad Hill - due 2012-05-09].
17:38:11 [jrossi]
It seems the conference bridge's audio has stopped.
17:38:28 [abarth]
jrossi: we had problems with feedback
17:38:53 [jrossi]
Ah, I see. I'm fine with just watching the IRC if you guys take good notes. :-)
17:39:09 [dveditz]
can you hear now?
17:39:18 [ekr]
we can hear you
17:39:21 [dveditz]
I think we hear you
17:39:40 [ekr]
next agenda item: CSP 1.0 outstanding issues
17:40:38 [bhill2]
can you still hear us?
17:40:49 [jrossi]
cuts out most of the time, just bits and pieces
17:40:49 [dveditz]
we all came to microsoft's campus, where are you? ;-)
17:40:55 [jrossi]
haha, wrong campus!
17:41:04 [abarth]
http://www.w3.org/2011/webappsec/track/issues/open
17:41:12 [dveditz]
jrossi: most of us are far from the mic, we'll try to get closer when we say something substantive
17:41:18 [dveditz]
right now there's lots of mumbling
17:41:29 [jrossi]
that's probably it, I think noise cancellation is just kicking in since you're far away
17:41:31 [ekr]
abarth: I thought we resolved issue 8 a while ago
17:41:57 [dveditz]
if *you* have noise cancellation you might try turning it off if you have a headset
17:42:03 [ekr]
issue 35:
17:42:05 [puhley]
puhley has joined #webappsec
17:42:10 [dveditz]
that way your own noise won't cut our softer sounds off
17:42:28 [jrossi]
i'm muted
17:42:55 [ekr]
dveditz: A lot of proxies will mangle this anyway
17:43:01 [ekr]
bhill2: this came out of IETF
17:43:25 [ekr]
dveditz: mozilla's solution was to have an intersecting policy
17:43:37 [ekr]
... I don't think we can say don't combine this
17:43:51 [ekr]
abarth: if there is a comma, there is an error processing case.
17:44:09 [ekr]
dveditz: the proxies will just merge them anyway.
17:44:33 [ekr]
abarth: how shall we handle the error of the server sending multiple errors and the proxy combining them.
17:44:42 [ekr]
dveditz: I can see how this happens.
17:45:26 [JeffH]
JeffH has joined #webappsec
17:46:04 [ekr]
[... discussion...]
17:46:14 [ekr]
Abarth and Dveditz suggest that comma be illegal.
17:46:24 [ekr]
abarth: how shall we handle it?
17:46:41 [ekr]
dveditz: I would prefer an intersecting policy
17:47:51 [ekr]
ekr: why not treat it as an ilelgal policy?
17:48:55 [ekr]
abarth: what should be the behavior if you get a policy without any of the known directives?
17:49:05 [ekr]
dveditz: shouldn't that be default source = none
17:50:44 [ekr]
tanvi/dveditz: why not take the most restrictive?
17:50:51 [ekr]
abarth: it's not clear which one it is?
17:51:00 [ekr]
... and now you're into intersecting policies
17:51:09 [ekr]
bhill2: this text I sent is designed to create this.
17:51:16 [ekr]
s/create/cover/
17:52:47 [ekr]
abarth: turns out that comma is forbidden but we recover
17:53:03 [ekr]
... I suggest that with comma we set the policy to some invalid policy.
17:53:19 [ekr]
bhill2: like default src = none
17:53:35 [ekr]
abarth: yeah, and I would probably log in the error console.
17:54:39 [ekr]
ekr: how should we handle other cases where the policy is invalid,
17:54:49 [ekr]
abarth: e.g., directive name == backspace or dollar sign
17:55:14 [ekr]
abarth: currently it gets parsed as a directive name. It's illegal but causes no failure.
17:56:35 [ekr]
ekr: the general philosophy is that if you can make sense of it, do it?
17:57:21 [ekr]
abarth: it's semicolon delimited, so if I don't understand the thing in between the semicolons, then I ignore it.
17:57:37 [ekr]
ekr: Do we want to revisit the design decisions (a) no intersection and (b) non-restrictive default policies.
17:57:43 [tanvi1]
tanvi1 has joined #webappsec
17:58:11 [ekr]
dveditz: I wasn't paying that much attention before, but I would still prefer intersection
17:58:36 [ekr]
bhill2: the argument last time was that intersection was hard
17:58:49 [ekr]
dveditz: yah, it's not perfect. It does tend towards breaking the page.
17:59:12 [ekr]
bhill2: what about combining only policies of type src list
17:59:56 [ekr]
abarth: most important thing is for it to be extensible.
18:00:16 [ekr]
... want to have something good I can take back to websec
18:00:33 [ekr]
... can't merge on a directive by directive basis
18:01:13 [ekr]
... I see policy combination as really complicated and benefit is not that large
18:01:29 [ekr]
dveditz: what is the proposed handling if we get a comma?
18:01:56 [ekr]
abarth: the thought is that since it is syntactically invalid, the policy is now default source none and print something to the debug console.
18:03:16 [ekr]
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
18:03:50 [ekr]
ekr: right, but this means that a bad policy is ultra-dangerous as opposed to breaking everything
18:04:01 [ekr]
bhill2: philosophy has always been that this is a safety belt
18:05:08 [ekr]
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.
18:05:32 [ekr]
... I would like to have some way to ask it.
18:06:32 [ekr]
bhill2: what if there is some proxy elsewhere.
18:07:57 [ekr]
ekr: what if there are multiple proxies? This makes it very dangerous...
18:08:13 [ekr]
abarth: do proxies like this really exist?
18:08:41 [ekr]
tanvi: so if we have two headers right now we do nothing?
18:09:05 [ekr]
tanvi: the other thing about intersecting policies is if we have meta tag and policy URI we might have to deal with this.
18:09:13 [ekr]
abarth: meta tag used to be trumped by header
18:09:53 [ekr]
abarth: 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
18:10:11 [ekr]
bhill2: how he handle combination logic, then this impacts how things behave in the future
18:10:40 [ekr]
... in the future, we are going to have proxies which do CSP injection, then this won't work with any future meta tag
18:11:11 [ekr]
abarth: maybe say you must only send one policy and then if you receive two you fail in some obnoxious way.
18:11:33 [ekr]
and if we add a new way to get policies we specify a combination mechanism then.
18:12:23 [ekr]
bhill2: this still leaves it open how people who do want to do policy injection. We should give them some advice.
18:12:32 [ekr]
abarth: those people are more able to adapt.
18:13:24 [ekr]
bhill2: well, WAFs don't adapt much
18:13:59 [ekr]
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
18:14:21 [ekr]
abarth: my current proposal {two policies, comma in header} --> enforce default src=none
18:14:45 [ekr]
bhilll2: so no meta tag?
18:15:06 [ekr]
... may need to discuss it later
18:15:18 [ekr]
s/may need to discuss it/it's on the agenda/
18:15:31 [ekr]
bhill2: is now a good time to discuss the meta tag for 1.0?
18:15:39 [plh]
plh has left #webappsec
18:15:43 [ekr]
abarth: I think we should talk about that in 1.1
18:15:51 [ekr]
... it's related to other things in 1.1
18:16:39 [ekr]
bhill2: 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.
18:16:43 [ekr]
dveditz: how so?
18:16:52 [Zakim]
+??P1
18:16:59 [ekr]
... other headers with meta tags have had the header override the meta tag
18:17:26 [Zakim]
-??P1
18:17:29 [ekr]
tanvi: what if we forbid duplication now and then specify merging in 1.1?
18:17:37 [ekr]
travis: historically don't meta tags trump headers
18:17:45 [ekr]
dveditz: tuypically the other way around
18:18:08 [ekr]
travis: from a security perspective, that seems ok, but practiclaly don't you want the opposite
18:18:16 [ekr]
abarth: that's just the way the web is even if it's backwards
18:18:29 [ekr]
travis: well, in some cases IE does that
18:18:47 [ekr]
dveditz: it's a matter of who wants what -- web pae authors versus site operators
18:19:29 [ekr]
travis: personally I want to not see meta tags in 1.0 so we finish
18:19:33 [abarth]
http://www.w3.org/2011/webappsec/track/issues/open
18:19:50 [ekr]
taking a break till 11:30
18:24:27 [abarth]
abarth has joined #webappsec
18:25:17 [tanvi1]
http://www.w3.org/TR/CSP/
18:25:41 [Travis]
Travis has joined #webappsec
18:26:15 [tanvi]
tanvi has joined #webappsec
18:29:36 [ekr]
ekr has joined #webappsec
18:29:52 [ekr]
we are back
18:30:37 [ekr]
topic is ISSUE #8
18:32:36 [ekr]
balance between the user's preferences and the site authors
18:33:31 [ekr]
dveditz: both user and site operator are concerned about attacks and the user can always override the site's preferences as a technical matter
18:33:51 [ekr]
abarth: my sense is that we agree about principles, and the details are a matter of the implementations which vary anyway
18:34:10 [ekr]
dveditz: if the UA lets the user add extensions, we are still respecting CSP in a reasonable way.
18:34:58 [ekr]
abarth: I view the current text as sort of aspirational.
18:35:24 [ekr]
... as an example, in Chrome a content script can load images from its own extension package regardless of CSP
18:35:51 [ekr]
ekr: I propose we mark this closed and move onto meta and sandbox
18:36:05 [ekr]
bhill2: we have requests from a bunch of people to restore the meta tag
18:36:30 [ekr]
... my summary is that there are a lot of site admins who can't set headers but would like to use CSP
18:36:46 [ekr]
... so this is worth the risk
18:37:34 [ekr]
abarth: my sense is that this interacts with CSP 1.1 proposed features such as the ability to query policy
18:38:04 [ekr]
dveditz: I'm much more concerned with a DOM API to set policy than I am about a meta tag
18:38:23 [ekr]
abarth: is there anyone who thinks this should be in 1.0?
18:38:35 [ekr]
tanvi:we'll need to discuss anyway
18:39:04 [ekr]
dveditz: one concern about injectable policy via meta is leak via reporting. maybe add same origin requirement for reports in meta
18:39:19 [ekr]
... would also like to restrict meta to HEAD
18:39:58 [ekr]
abarth: how would you feel if we restricted meta tag to HEAD. How would you feel if someone injected it later?
18:40:03 [ekr]
dveditz: I think that's cheating
18:40:27 [ekr]
abarth: so only if it's in head and available at the start.
18:40:35 [ekr]
... example is gmail
18:41:19 [ekr]
dveditz: what if I had a meta tag that said "allow deferred DOM API CSP injection later"
18:42:01 [ekr]
bhill: use cases is restrictive server environments
18:42:19 [ekr]
... maybe these use cases can't meaningfully consume reports anyway
18:43:31 [ekr]
dveditz: might be willing to stick to simplest sue cases
18:43:37 [ekr]
s/sue/use/
18:43:58 [ekr]
tanvi: what would requirements be: meta tag == no report, meta tag must be in HEAD, must be no header
18:44:09 [ekr]
abarth: + must be inserted by parser
18:45:21 [ekr]
[discussion about what 'inserted by parser']
18:45:23 [Zakim]
+ +1.858.485.aacc
18:46:51 [ekr]
[discussion about what we are trying to achieve by restricting this?]
18:47:05 [ekr]
bhill2: if you can inject script then it's game over
18:47:17 [ekr]
... I'm not sure there is any reason to restrict it from being added by script
18:47:17 [Zakim]
+??P2
18:49:06 [ekr]
dveditz: the spec should just recommend that it go early.
18:49:56 [ekr]
bhill2: if you screw up before the meta, you're on your own
18:50:07 [ekr]
dveditz: want same origin reports
18:50:23 [ekr]
tanvi: don't want same origin reports--encourage people to use header instead of meta tag
18:51:47 [ekr]
bhill2: if you're only able to run static comment anyway
18:51:55 [ekr]
... how many scenarios is this relevant for?
18:52:31 [ekr]
tanvi: the only places this is really going to happen are corp environments and those people should go talk to their admins
18:52:35 [ekr]
abarth: my notes say
18:53:02 [abarth]
Bringing back the <meta> tag,
18:53:02 [abarth]
Must be in the <head>
18:53:04 [abarth]
Header trumps <meta> tag
18:53:05 [abarth]
First <meta> tags wins
18:53:06 [abarth]
report-uri doesn’t work
18:53:07 [abarth]
Guidance that delaying the header isn’t wise
18:54:40 [ekr]
dveditz: meta must come through parser.
18:54:56 [ekr]
bhill2: what's the security benefit here? All you can do is inject a new policy?
18:55:50 [ekr]
abarth: my preference is to not care how the data is inserted.
18:56:14 [ekr]
abarth: suggestion is to use no insertion after ready state.
18:57:46 [gioma1]
Zakim: ??P2 is gioma1
18:58:16 [ekr]
ekr: what's the security reason for this?
18:58:31 [ekr]
bhill2: It seems like an implementation simplification
18:58:37 [ekr]
ekr: ok
19:01:32 [Zakim]
- +1.858.485.aacc
19:02:41 [abarth]
abarth has joined #webappsec
19:03:33 [Zakim]
-[Microsoft]
19:04:10 [ekr]
ekr has joined #webappsec
19:20:30 [ekr]
ekr has joined #webappsec
19:23:45 [ekr]
topic: should we have meta in 1.0 or not?
19:24:00 [ekr]
nobody in room wants it in 1.0. people on list have requested ti
19:24:14 [ekr]
dveditz: we are probably closer to meta than sandboz
19:24:25 [ekr]
bhill2: if all implementors agree they don't want to do meta in 1.0
19:25:02 [ekr]
... then it doesn't need to be in 1.0 spec. by comparison, sandbox has some implementation. but no implementations, then meta loses...
19:25:35 [ekr]
tanvi: just because it's not in 1.0 doesn't mean people don't do it
19:25:43 [ekr]
abarth: my plan is to ahve it with a prefix
19:27:11 [ekr]
resolved: meta will be in 1.1 due to lack of implementor support for having it in 1.0. we will attempt to specify it early in 1.1.
19:27:36 [tanvi]
tanvi has joined #webappsec
19:28:25 [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
19:29:06 [ekr]
bhill2: anyone want to revisit consensus on sandbox. We had interest from implementors on doing it, and we're going to re-check implementation status at CR...?
19:29:09 [dveditz]
abarth was going to use wording along the lines of "before document readystate"
19:31:11 [tanvi]
does microsoft have the full csp 1.0 implemented?
19:33:54 [ekr]
abarth: can we have a feature that we may drop if we do not have two implementations?
19:34:02 [ekr]
philippe: you need to mark it as "at risk"
19:35:53 [ekr]
philippe: if you mark it as at risk, you don't need to recycle to LCWD if you drop it.
19:38:34 [ekr]
proposed resolution: we mark this at risk and then if we don't have two implementations, it gets dropped.
19:41:02 [ekr]
bhill2: can MS live with having this in 1.1?
19:41:21 [ekr]
travis: main concern is that it not just look like a MS feature
19:41:52 [ekr]
bhill2: jacob is willing to specify this
19:42:24 [ekr]
abarth: we outsource parsing to HTML5
19:42:57 [ekr]
dveditz: what if HTML5 changes?
19:43:04 [ekr]
abarth: they need to retain backcompat
19:43:36 [ekr]
bhill2: propose that we punt this to 1.1 since MS won't have a complete implementation anyway. Then we can move to LC soon.
19:43:47 [ekr]
... will raise on list
19:43:59 [ekr]
action: abarth to create 1.1 impl by end of week
19:43:59 [trackbot]
Created ACTION-59 - Create 1.1 impl by end of week [on Adam Barth - due 2012-05-09].
19:45:40 [ekr]
resolved: we will punt Sandbox to 1.1 pending approval on list.
19:46:55 [ekr]
dveditz: what about future compatibility for more specific policies, e.g., src lists that specify directories
19:47:21 [ekr]
... if we come up with a compatible syntax now.
19:47:49 [ekr]
abarth: proposal, allow full URLs but truncate to the origin.
19:50:01 [abarth]
script-src http://example.com http://foo.com/bar/qux
19:50:40 [bhill2]
dveditz: if someone types in https://www.google.com/ that is ignored because of trailing slash
19:50:42 [tanvi]
script-src 'self' http://dev1.addons.phx1.mozilla.com https://addons-dev-cdn.allizom.org/
19:53:10 [tanvi]
proposal: allow urls, and truncate them to the origin.
19:54:20 [tanvi]
this ends up whitelisting an entire origin, when perhaps you just want to whitelist a path.
19:54:27 [tanvi]
so perhaps we shoudl version cps?
19:54:31 [tanvi]
*csp?
19:54:57 [tanvi]
script-src and scipt-src-path
19:56:56 [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.
19:57:31 [dveditz]
choices appear to be a) version CSP header, b) duplicate directives in the future, c) degredation of hosts with paths
19:58:16 [dveditz]
a) means two headers always. CSP2 clients need to look for both headers, sites may just leave CSP1 clients insecure
19:58:41 [dveditz]
b) pretty much the same on a directive level -- either duplicate, or leave CSP1.0 clients as insecure as non-CSP clients
20:05:06 [ekr]
action: dveditz to write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin)
20:05:06 [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].
20:05:56 [ekr]
dveditz: people also want to be able to specify plugins by media type. E.g,, flash but no java
20:13:32 [ekr]
action: abarth to merge bhill's policy combination text into the CSP document
20:13:32 [trackbot]
Created ACTION-61 - Merge bhill's policy combination text into the CSP document [on Adam Barth - due 2012-05-09].
20:14:49 [abarth]
http://www.w3.org/Security/wiki/Content_Security_Policy
20:15:01 [abarth]
https://mikewest.org/2012/05/content-security-policy-feature-detection
20:21:38 [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 :(
20:25:22 [jrossi1]
jrossi1 has joined #webappsec
20:28:17 [bhill2]
talking about CSP 1.1 propsed features right now
20:28:25 [bhill2]
I will try to turn up the microphone
20:28:51 [tanvi]
i believe the anti-clickjacking discussion is tomorrow
20:30:39 [ekr]
http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0016.html
20:43:26 [ekr]
Topic: CSP access API?
20:43:31 [ekr]
http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1
20:44:43 [ekr]
peleus: what happens if you try to eval() with SCP
20:44:45 [ekr]
CSP
20:45:04 [ekr]
abarth: throw a security exception
20:45:38 [ekr]
abarth: why is this useful? Avoid reporting errors for feature tests
20:46:58 [ekr]
Topic: frame-ancestor or frame-options
20:47:16 [ekr]
abarth: maybe we can get this back in
20:49:33 [ekr]
jeffh: now is a good time to participate in websec
20:49:50 [ekr]
abarth: maybe it should be possible for IETF documents to specify CSP directives
20:50:45 [tanvi]
i have a couple of potential additions i'd like to bring up
20:50:49 [ekr]
bhill2: 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
20:50:57 [ekr]
tanvi: you have access to the wiki?
20:51:20 [ekr]
I just added some stuff
20:51:34 [tanvi]
sure, i'll do that
20:53:44 [tanvi]
added
20:53:58 [ekr]
topic: script-hash
20:54:05 [ekr]
peleus: this seem like it's a maintainability issue
20:54:11 [ekr]
dveditz: this starts to get pretty long
20:54:40 [ekr]
... what about policy-uri?
20:55:26 [tanvi]
this way you could imbed third party script that you trust (ex: facebook like widget) and know that if facebooks servers gets compromised, the hash won't match and your page won't be vulnerable
20:55:35 [tanvi]
(regarding script-hash)
20:57:37 [tanvi1]
tanvi1 has joined #webappsec
20:57:53 [tanvi1]
script-src http://google-analytics.com [###]. so only http://www.google-analytics.com/ga.jsworks, and nothing else from google-analytics works.
20:58:47 [tanvi]
tanvi has joined #webappsec
21:00:10 [ekr]
topic: no-user-js
21:00:22 [ekr]
tanvi: idea to prevent against self-xss.
21:00:28 [ekr]
no longer allow js: in address bar
21:00:46 [ekr]
but you could still get people to do "open"
21:01:33 [ekr]
idea would be to require special to activate the web console in these cases (where policy is provided)
21:02:04 [ekr]
dveditz: not sure how serious this is.... it is for fb and twitter
21:02:32 [ekr]
really only applies to a subset of sites.
21:03:13 [ekr]
ekr: this is a social engineering question
21:03:38 [ekr]
dveditz: interesting idea but not sure I want to jump right in on it.
21:04:58 [ekr]
next topic: restrict script to sources with specific content types
21:05:39 [ekr]
peleus: this causes a lot of problems
21:06:00 [ekr]
tanvi: idea here is to restrict scripts to a specific set of content-types
21:07:40 [ekr]
abarth: historically, this has been something people have ignored, so there will be a lot of collateral damage
21:08:01 [ekr]
... having it be opt-in
21:08:20 [ekr]
ekr: you could have the white-list in the directive
21:08:30 [ekr]
abarth: etter to ahve it be binary
21:09:04 [ekr]
topic: form-action
21:10:19 [ekr]
bhill2: HTML5 makes form tag injection easier
21:11:38 [ekr]
abarth: this seems like it would help defend agains that and be within the scope of the kind of stuff we have done
21:11:45 [ekr]
topic: plugin-types
21:11:54 [ekr]
dveditz: syntax seems complicated
21:11:58 [ekr]
... argue about it later
21:12:15 [ekr]
abarth: seamless with parent
21:12:36 [ekr]
... iframe can resized like a div.
21:13:38 [ekr]
... right now it's single origin
21:13:51 [ekr]
... might be nice to have a directive that allows it even without same origin
21:14:04 [ekr]
ekr: this seems like it's conceptually new since it's not a restriction
21:14:13 [ekr]
travis: IE already allows iframe resizing
21:14:18 [ekr]
abarth: this is a little different
21:15:02 [ekr]
... put it here so the group is aware of it. not sure where it goes
21:15:47 [ekr]
topic: jsonp with padding
21:16:10 [ekr]
bhill2: a lot of people want to have safe JSONP
21:16:28 [ekr]
... jsonp-src : a list of domains
21:16:38 [ekr]
... jsonp-sink: a list of safe function names
21:16:52 [ekr]
... idea is that you could apply it to existing legacy code
21:23:17 [ekr]
bhill2: 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
21:24:12 [ekr]
ekr: this seems like a good idea, but not sure it can be made to work
21:25:35 [ekr]
abarth: I had one more... meta-referrer
21:26:54 [ekr]
finally, more granular origin list
21:28:25 [ekr]
tanvi: who has implemented meta tag for referer?
21:29:13 [ekr]
dveditz: should this be a meta tag? separate or in csp?
21:29:27 [ekr]
abarth: this feels like a policy thing
21:29:54 [ekr]
dveditz: I agree with that for things that are specified as headers....
21:31:24 [Morton]
Morton has joined #webappsec
21:31:45 [ekr]
bhill: distinction between proposals that rev the spec and proposals that add new directives
21:33:36 [ekr]
bhill: what are examples of reving the spec? policy-uri, more granular origins
21:34:35 [ekr]
abarth is currently modifying the page to divide between experimental and proposals for 1.1
21:36:21 [ekr]
abarth: excited about form action
21:37:08 [ekr]
abarth: plugin types might be a good one
21:37:24 [ekr]
bhill2: negative plugin tyes?
21:45:18 [abarth]
abarth has joined #webappsec
22:07:13 [ekr]
rrsagent, create minutes
22:07:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/05/02-webappsec-minutes.html ekr
22:07:54 [ekr]
rrsagent, make public
22:07:54 [RRSAgent]
I'm logging. I don't understand 'make public', ekr. Try /msg RRSAgent help
22:08:28 [ekr]
RRSAgent, please make logs world-visible
22:17:12 [mkwst]
mkwst has joined #webappsec
22:20:49 [abarth]
https://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/contentSecurityPolicy
22:27:37 [tanvi1]
tanvi1 has joined #webappsec
22:27:58 [tanvi1]
tanvi1 has joined #webappsec
22:28:11 [tanvi1]
tanvi1 has joined #webappsec
22:28:25 [tanvi]
tanvi has joined #webappsec
22:32:00 [Peleus]
Peleus has joined #webappsec
22:51:07 [Zakim]
-??P2
22:54:08 [puhley]
puhley has joined #webappsec
23:19:32 [ekr]
ekr has joined #webappsec
23:26:15 [gopal]
Hope your VM is up
23:26:28 [gopal]
please switch to branch testJam
23:26:45 [gopal]
and add your tests on this branch
23:57:49 [tanvi1]
tanvi1 has joined #webappsec
23:58:05 [Zakim]
- +1.650.693.aaaa
23:58:06 [Zakim]
SEC_WASWG()12:00PM has ended
23:58:06 [Zakim]
Attendees were +1.650.693.aaaa, +1.858.485.aabb, [Microsoft], +1.858.485.aacc