Web Application Security Working Group Teleconference

23 Mar 2016


See also: IRC log


mkwst, bhill2, freddyb, francois, gmaone, teddink, dveditz, terri, tanvi, ckerschb
bhill2, dveditz


<trackbot> Date: 23 March 2016

<scribe> scribenick: bhill2

<scribe> Meeting: WebAppSec Teleconference, 23-Mar-2016

<mikeoneill> Hi Im Mike O'Neill in webex

<mikeoneill> via webex I meant

wseltzer: can we chat about some document statuses later?

transition request for CORS to edited REC is stale as of Sep 9 (!) and SRI to Proposed REC from Jan 22...

<wseltzer> bhill2, yes, and about fetch dependencies.

yes, great

Agenda is here: https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0073.html

<scribe> scribenick: bhill2

Agenda Bashing

Minutes Approval


Any objections to unanimous consent to approve prior minutes?

No objections, approved unanimously.

May F2F

Thanks to Moz for volunteering space at Mountain View on May 16-17.


Agenda bashing for F2F


mkwst: implementer interest is most important topic, and threat model discussion flows nicely into that
... what do various vendors actually care about and where should we be investing our effort

dveditz: agreed on that, a few things not mentioned
... like CSP2. Let's go through all specs and what next steps are, where are we in the process for each one.

<mkwst> bhill: Removing barriers is on the list. But doing inventory seems like it makes sense.

<mkwst> ... Very close on CSP2.

<mkwst> ... One or two features (`form-action`) that don't have two implementations.

<mkwst> ... Remove those features? Make them optional?

<mkwst> ... Want to get to REC.

Finalizing Mixed Content to Proposed Recommendation


Mike said on the list that if the context isn't secure, the content isn't mixed.

tanvi: thought there was discussion that directive and UIR should work on insecure pages, too

mkwst: UIR works on insecure pages and still tries to upgrade insecure requests
... but block all mixed exits early if not in a secure context because content isn't actually mixed

tanvi: sounds fine, actually how our implementation works

dveditz: if you are an insecure page and framed a secure page then you would have strict blocking for the secure frame, yes?

mkwst: that is correct

dveditz: should make sure we have a test case for that

mkwst: I don't feel strongly about that behavior
... fine to change to indicate that the directive only works in a secure context

dveditz: I care that FF, Chrome and other browsers are consistent in cases like that

mkwst: fairly certain that behavior is well-defined. flag set on document that propagates down into iframes
... will test this

sri source expressions

<mkwst> bhill: Will hold off on officially doing anything until tested. Sounds like it'll be quick.

neilm: idea is to add another directive to CSP to indicate that resources must have integrity tags

seems to be pretty good consensus on this...

neilm: there is some contention on whether we want a directive to require on all resources, e.g. * as an equivalent to default-src: none

dev: I prefer a new keyword expression for each individual -src directive rather than a new CSP directive
... for forwards/backwards compatibility reasons

francois: I'm fine with either a global keyword or something in each -src directive
... I think that '*' is likely to cause problems in the future when browsers implement at a different pace

neilm: would become a big problem if things were wildly all over the place
... don't know it will be that disjoint. some of that already with things like nonces that some browsers don't understand

francois: I fear that lots of devs will use * because it is shorter, and it only applies to styles, scripts, site will break in the future as new tags are supported

dveditz: or require an integrity attribute on everything with a href and break even if we don't check it

dev: so many tags...

francios: still an issue if we invent a new type of subresource

neilm: and pretty long

<freddyb> I suggest we don't support * but allow shorthands for sets of subresources by spec version, i.e. v1 = scripts & styles

bhill2: I would lean towards not giving developers a footgun, we had to scramble at Facebook to fix when data: and blob: were no longer implicitly part of *

dev: I vote for not including a *

francois: bring up the github discussion to the list

neilm: will do it

permissions delegation





tanvi: I've commented on the proposal, but don't think that Raymes is here

mkwst: neither Raymes or Chris is on the call...
... not sure how much value there is in discussion without either proposer

<mikeoneill> q

mkwst: I like it, think it's good and some tweaks proposed are interesting

<mikeoneill> +q

mikeoneill: I quite like it, also interested in the cookie control and embedded CSP thing from December
... seem to be addressing the same issue, would be good to discuss at the same time

<mkwst> bhill: Yes. Fits in with the conversation around threat models.

<mkwst> ... embedded widgets, ads. What control do we want to give to the embedder.

<mkwst> bhill: AOB?

<mkwst> ... Need to update CORS to point at Fetch.

<mkwst> ... Transition requests gone stale.

<mkwst> ... Need to talk with Web Platform WG to see what's going on with references to HTML.

<mkwst> ... WHATWG, etc.

<mkwst> ... mkwst is interested. Anyone else?

<mkwst> <crickets>

<mkwst> ... Will get that on the calendar.

mkwst: issued an intent to ship same site attribute for cookies
... want to bring it to the attention of other browser vendors, please take a look

ccowan: can you give us the elevator pitch?

mkwst: if a cookie is marked as same-site, it will only be sent if the request is initiated by the same site
... example.com requesting something from example.com will send the cookie, evil.com requesting something from example.com won't have it

<mkwst> bhill: How to feature-detect?

<mkwst> ... would love to use this if we know it'll be respected.

<mkwst> ... Want to know if the semantics will be forced or not.

<mkwst> dveditz: Looking at it as an opportunistic improvement.

bhill2: would be good to know if the semantics are enforced without having to do UA string assessment

<mkwst> ... What would you do in a UA that doesn't support?

<mkwst> ... Works on browsers that don't support, but get more protection on browsers that do.

dveditz: think of it as an opportunistic improvement

<mkwst> bhill: Some scenarios where you're trying to protect against CSRF'd login into some arbitrary account.

<mkwst> ... Might want to take other measures depending on the capability of UA.

<mkwst> dveditz: Would have to signal in the cookie itself

<mkwst> ... can't really decorate the cookie header without breaking soething.

<mkwst> ... could add a signaling header.

<mkwst> devd: Prefixes?

dev: what about prefixes as a secondary mechanism?

<mkwst> mkwst: That would mean we'd need to signal support for prefixes.

<mkwst> bhill: DOM attribute would be enough for me.

<mkwst> ... `document.cookies.supportsSameSite`, etc.

<mkwst> ... Will think on it some more.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2016/03/24 16:54:01 $