See also: IRC log
<trackbot> Meeting: Web Application Security Working Group Teleconference
<scribe> scribe: Brad Hill
<wseltzer> present=bhill2, francois, MikeSmith, wseltzer
<dveditz> I'm not here yet
<scribe> scribenick: bhill2
<teddink> Ted Dinklocker here - I am on the clal, but not sure if my microphone will work well.
(minutes are fixed now, Dan)
(forgot to run my script after last week's call)
bhill2: still planning to do the interest matrix discussed on last week's call
<Zakim> MikeSmith, you wanted to comment
MikeSmith: I work for w3c along
with Wendy
... 1st: heads up on recent addition of CSP support to the
syntax checker
... 2nd: relatively recently we deployed TLS support to w3c
with HSTS and some CSP stuff and wanted to propose that on a
future call we get Jose from the systems team to give some
feedback
... as a site administrator on deployment of some of that
stuff, esp in respect to information sources used
... Last agenda proposal: interested in hoping some CSP related
specs move along, e.g. SRI and referrer policy
... anything I can do to help those move along faster
https://www.w3.org/2016/01/27-webappsec-minutes.html
also now at the usual spot: https://www.w3.org/2011/webappsec/Minutes.html
bhill2: 1st half of May, Bay Area South is winning with 9 votes, including likely visitor from Apple/Safari
<dveditz> bhill2: poll shows early May winning (9) followed by early April and late May (8)
wseltzer: procedural matters are that we need to get notice 8 weeks before it is scheduled to take place
<dveditz> ... silicon valley the runaway winner
wseltzer: anyone willing to host?
dveditz: Mozilla can perhaps host in Mountain View
tanvi: we can probably get enough space in Mozilla Mtn View
bhill2: I will reach out to Apple
and PayPal and see if they might want to host south
... and thank you to Mozilla for volunteering and kind and fun
hosting in the past of this group
... Mike West's responses indicate that 1H May in Bay Area
works for him
dveditz: should referrer policy
impact Origin header? recently started doing so in Chrome, in
particular if referrer policy is none
... if doing CORS, have to send Origin header
... other spec suggests sending it all the time, but then some
servers think this is a CORS request
bhill2: we found this at Facebook, specifically with same-origin requests where null Origin header was being sent
<wseltzer> tanvi: what happens if the user decides to suppress the referrer?
tanvi: also need to decide what to do with Origin header if user sets a preference to not send referrers
dveditz: moz has that in buried
prefs somewhere but no standard
... would treat it as if page set no-referrer, should probably
resolve it the same
... leaving aside Mozilla's hidden preference switch,
extensions, etc.
... if a page said no referrer, that page is also the one
trying to get a service from a page that wants an Origin
... should be up to the page author to resolve it with referrer
policy
... otherwise no meaning to ability to set no-referrer
bhill2: origin-when-cross-origin
is sort of ok here
... probably should put together a table describing the
states
... maybe add none-when-cross-origin
dveditz: there are 10 or so possible states, only 4 expressed by policy
tanvi: would like to extend, maybe should discuss on a github issue
dveditz: then maybe flexible enough to suppress Origin as well
bhill2: and should call out that CORS-mode requests still send origin
dveditz: also maybe indicate
suppression vs. null (distinguish from redirect)
... is there a spec for the Origin header
<wseltzer> https://tools.ietf.org/html/rfc6454
bhill2: but this RFC is not in sync with what CORS does
(and this mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=446344)
dveditz; a recurring topic is a way to indicate that SRI is required
scribe: doesn't look like we have
the editors on this call today
... I would like to reject a global flag that says "require
this for everything"
... pages that say this would then break if we extend the
applicability of the attribute to e.g. images
... could add keywords to directives, e.g. 'require-integrity'
to script-src
... worry that sites may not want to do that
... may be sites they don't want to require integrity for
... e.g. not for same-origin
<francois> so maybe something like "script-src sri+https://cdn.example.com"?
scribe: starts to get complex, difficult to fit into CSP syntax
bhill2: we already can express
this by using hash syntax, but gets unweildy
... maybe proposals to support signing keys make this simpler
to express
... so, like francois' suggestion but <key>+https://cdn.example.com/
... Adding, e.g. a key in the header provides stronger
injection defense
... whereas an adversary that can inject also knows the hash
value
dveditz: thinks people who wanted
it wanted to not forget to add it themselves
... no signing mechanism yet, though people are experimenting
with it
francois: in my mind, signatures
are separate from require integrity proposals
... proposed by GitHub, want to make sure they don't
accidentally add things outside of policy
... or forget to add SRI hash
(francois - you are breaking up)
(garbled)
scribe: sounds a lot like CSP,
restrict accidentally introduced things
... more unknowns around signatures
... require integrity may be easier to get done and can be
integrated into CSP in a good way, also get reporting with
it
bhill2: I think this is a great place to experiment and prototype ahead of spec text
dveditz: one of the more active
threads on the list
... unless anyone has something to say, should move on
dveditz: proposal from David
Ross, "Safe Node", Mario Heidrich gave a talk at Enigma Conf on
a similar idea
... toStaticHTML is in IE, was at one point w/ a WHATWG
spec
... is our WG the appropriate place for it, or should we leave
it to the platform group?
bhill2: happy to have the discussion on this list with the right experts but would want to see stronger prototyping and feedback cycle before I'd support an official WG draft
<wseltzer> https://validator.w3.org/
MikeSmith: recently I deployed
CSP syntax checking support in the W3C validator that checks
the value of the meta http-equiv
... content attribute if the value is content-security-policy
and also checks the csp header if document is delivered with a
header
... using library called Salvation from Shape Security
... wasn't completely up to date with current spec, gave some
patches and seems to be correct now
... e.g. support for upgrade-insecure-requests
... was important for us at w3c as we deploy TLS with otherwise
millions of instances of mixed content
... aligns with current CSP3 spec and also related specs
... validator sees on order of 12-15 requests / second
... lots are requests from normal devs trying to check their
content
... has potential to get a lot of awareness raised about CSP
and get a lot of people using it and fixing problems
... mostly an FYI, one open issue
<MikeSmith> https://github.com/validator/validator/issues/207
MikeSmith: sergei is ambitious
about not only doing syntax checking but also doing real CSP
checking against document content and CSP requirements
... take a look, get in touch with me if you are interested in
refining or improving it
(timeless: yes, someone has their hangouts or similar making noise)
MikeSmith: don't have information to summarize our deployment in detail
MikeSmith: but one thing I have
from Jose - he was confused and frustrated by state of CSP
spec
... had difficulty being able to determine which spec to work
from
... as a normal site admin trying to do a deployment
... what should he conform to
... CSP 1/2/3
... I got it, but I'm not him
... would be good if we could setup something to that Jose
could join a call and give the group feedback
... always good to get a chance to get real feedback on issues
folks are facing
dveditz: would be good to send an email first so we can use that to guide discussion on the call
<wseltzer> https://www.w3.org/Webauthn/
<dveditz> thanks for coming MikeSmith
yes, thanks much MikeSmith, awesome developments