Web Application Security Working Group Teleconference

<tanvi> i will be 10 minutes late today

<terri> I have overlapping meetings and will be irc-only for at least the beginning of this one

Agenda Bashing

<dveditz> scribenick:francois

<dveditz> scribenick: francois

<francois_> I don't know the magic zakim commands though, so you'll have to do that bit :)

<dveditz> scribenick: francois_

<JeffH> +

<JeffH> heh

dveditz: a few topics haven't made it to the schedule yet because i wasn't sure they were ready to be dicussed here
... for example, the security ui thread and the meta tag to lock away code (which nobody on this group seems to have interest in), also the long discussion on the topic of client certs (doesn't feel like it belongs to our group)

Minutes approval

https://www.w3.org/2011/webappsec/draft-minutes/2016-02-10-webappsec-minutes.html

<dveditz> https://www.w3.org/2011/webappsec/draft-minutes/2016-02-10-webappsec-minutes.html

<teddink> No objeciton

dveditz: minutes are approved unanymously

WASWG Face-to-face in May!

dveditz: poll results: first half of May won
... proposal is May 16-17 at Mozilla Mountain View

<dveditz> Tentatively May 16-17 at Mozilla in Mountain View, California

<dveditz> Who does that work for, who does it not?

https://www.mozilla.org/en-US/contact/spaces/mountain-view/

<estark> I think I can make it

<JeffH> i think i can make it

<KingstonTime> I'm not sure as I don't know what my status will be and what Mozilla is doing etc :D

dveditz: We will need a hand count at some point so that we can order lunch for people.

<teddink> I am working with folks at Microsoft to decide who should attend, I would expect at least 1 attendee.

<JeffH> just verified that week is clear on my calendar

<tanvi> i will be there

dveditz: this is the same week as Google IO, but IO is at the end of the week

RFC 7762 -- an IANA registry of CSP directives

<terri> I will make a travel request, not sure if I will be able to get a flight or not yet

dveditz: mkwst work with mark nottingham to set up this registry at the IETF. it currently has CSP 2 directives. doesn't have strict mixed content blocking or referrer policy directive, or upgrade insecure request
... this will enable CSP3 to be more of a framework and let other specs easily declare extra directives

Toward a minimum-viable Credential Management API

dveditz: mkwst took a stab at the credential management API to come up with a more limited spec that we're more likely to agree on and implement
... we'll need to coordinate with the web auth group to find out whether or not they can build on this
... the mozilla folks working on web auth aren't in this group

<dveditz> mailing list message: https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0046.html

mkwst: the current api does three things: let websites integrate with the password manager
... 2- hook into account creation / registration
... 3- framework for other groups to build stuff on top of
... of those things, chrome has implemented the first 2. based on their data, the first use case makes a lot of sense. it makes the password manager work better
... the sign up case (#2) was much harder
... in chrome we have not found a good way to make that work well
... e.g. if you logged using a password you don't save, the browser might prompt you to use facebook login next time
... the plan for chrome is to ship #1 in Chrome 50 or 51
... feedback is welcome on this plan
... we'll keep the ability for websites to tell the browser that a user logged in using facebook connect, but we're taking out the part where we synthesize credentials on the user's behalf

dveditz: is an updated spec coming to the proper channels?

mkwst: i'm waiting on some bikeshed work to happen and make that automatic

dveditz: there is a concern that our specs look stale from the w3c point of view, despite the github ones looking fine

mkwst: there is a large gap between github and w3c at the moment, my hope is that it will change soon

tanvi: mozilla hasn't currently prioritized that spec yet

Making it easier to deploy CSP ('unsafe-dynamic')

<JeffH> mike's plan for cred mgmt sounds fine by me

<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0048.html

dveditz: mkwst's proposal comes from Google's experience trying to implement CSP

mkwst: it seems like a valuable thing that would enable the google infra team to put CSP on more Google properties.
... dev was raising some issues asking whether or not the polyfill would be enough
... that requires nonces though and on some Google properties they would be using hashes because the pages are totally static
... it looks pretty sane from my point of view (and google's). i have an action item to draft a spec change for this

dveditz: it's a weaker form of csp, but it's still better than not using CSP at all

mkwst: the current practice of whitelisting origins is, for google, not as strong as we though it was. there are a lot of endpoints on ajax.google.com for example that enable JS injections (e.g. through old angular JS)
... the infra sec team is of the opinion that every large origin will run into this problem
... unless you whitelist individual files, you're going to have a bad day. and whitelisting individual files has proven too brittle to be deployed in practice

(see the thread on the list for the details of the proposal)

mkwst: we audit the scripts we know we're including on the webpages. we're ok with those scripts doign whatever they need to do (including loading more scripts that they need)

dveditz: are nonces allowed on script-src that's an actual script-src rather than inline scripts?

mkwst: yes

dveditz: interesting proposal adressing real-life pain that a large implementer is facing

Github issues and updates:

dveditz: reminder that a lot is happening on our github repos
... there was a good "issue" thread on cowl, one about null on the referrer policy
... there was a good discussion clarifying things about suborigins. it was probably the most active topic / spec since the last meeting
... interesting CSP discussion. apparently in Firefox, script hashes only apply to script tags, not onclick handlers
... it could be dangerous to allow these because attackers could copy these handlers and make them fire in other places on the page
... the alternative is to programmatically add the event handler from within the script
... if the mailing list seems quiet, that's because half of the conversation is happening on github

<teddink> Thanks!

<KingstonTime> Thanks all!

<JeffH> thx!

<dveditz> hm, well _that_ didn't work right.

<dveditz> wseltzer: wondering why Zakim thinks only jeffH was here

<dveditz> earlier there was a much larger "present" list