WebAppSec WG Teleconference, 16-Nov-2016

16 Nov 2016


See also: IRC log


bhill2, wseltzer, JohnWIlander, Daniel, Bates, mkwst, teddink, Deian, Stefan, dveditz, ArturJanc, terri, Crispin, Cowan
bhill2, dveditz
mkwst, bhill2_



Agenda Bashing

<bhill2_> none requested

<inserted> scribenick: mkwst

bhill2_: Normally we'd approve minutes.
... But the automated minute uploader is down. I'll fix that up sometime soon.


bhill2_: CSP2 is a proposed rec! Yay!

wseltzer: Reminder to remind your AC reps to support CSP2 -> REC.
... AC review, showing of support is helpful.

bhill2_: Implementation of CSP: Embedded Enforcement.
... `CSP-Allow-Origin`

<bhill2_> mkwst: allows an embedder to enforce a policy on an embedee

<bhill2_> ... suggest a policy for framed content, browser will only load if content agrees

<bhill2_> ... content agrees by a header listing what policy it agrees to, or if the enforced policy is subsumed by that policy

<bhill2_> ... right now we only do the CSP-Allow-Origin piece and are working on the other piece

bhill2_: Two requests for review.
... IndexedDB. Screen Orientation.
... Still working on a process for responding to these kinds of requests.
... Folks are encouraged to take a look at these documents and provide feedback.

deian: To what extent can we chime in here?
... For instance, IndexedDB says it doesn't handle PII, but some developers do store interesting data in these databases.

bhill2_: Everyone should feel encouraged and empowered to chime in.
... We're all responsible for the security of the platform.
... We're charted to advise.
... "Wide" review is intended to be wide.
... So say things if you think things should be said.

dveditz: Where do the reviews go?
... "File comments as GitHub issues." Got it.

wseltzer: Right, folks are generally moving to GitHub. Will tag issues as "security".

bhill2_: Group by group. Each call for review will generally specify how comments should be submitted.


bhill2_: Charter expires at the end of the year. Talked about this a bit a TPAC.
... Scope is pretty broad, covers the things we're thinking about.
... Anti-clickjacking might end up in Intersection Observer.
... Perhaps we should make room to give it a home?
... Discussion at TPAC.
... ArturJanc suggested that we specifically mention XSS and CSRF.
... And carve out room for SafeNode, etc.
... And deal with large problems like timing attacks and side channels.

wseltzer: A topic I'd like to bring to the group:

<bhill2_> wseltzer: we've been dealing with the question of normative references to Fetch for a while

wseltzer: Normative references to Fetch, etc.

<bhill2_> (will let you continue, mike, thanks)

wseltzer: Should that be in the charter more explicitly?
... Fetch in WHATWG poses something of a challenge to the platform because there's a split among implementers and developers about whether they're able to use it.
... IPR policy, royalty free commitments, process around recommendations.
... Important to some implementers.
... If we're not all looking at the same algorithms, that can cause security issues.
... Small details around hooks matter.
... Working to offer work modes that work with WHATWG.
... Still trying to do that.
... Looking to find a mode that works with WHATWG's existing development mode.
... Snapshot and bring levels of the spec through the REC process.
... Patent commitments attach at the time we hit REC.
... Living standards are great for lots of things. We also need snapshots.
... They're the pieces to which we can say folks have made patent commitments.

bhill2_: It would be great if we could come to agreement.
... Not sure we have anything approaching consent from the relevant authors.
... Wouldn't be unhappy to open up the possibility of bringing that into our scope.
... But probably best to bring into email, as it would be a substantial extension of our scope, so folks will need to bring it to their counsel.

dveditz: CORS?

bhill2_: We included CORS by saying we were looking at cross-origin mashups and cooperation.
... Fetch is bigger.

wseltzer: Taking that up would give us a clearer way to point people to active CORS development.

bhill2_: That was a concern I heard at TPAC.
... W3C version forks SEO, etc.
... Would be good to address those concerns.

wseltzer: Taking search engine traffic wouldn't be our goal.
... We can recommend a stable version, but recommend to implementers that they file bugs against the development version.

bhill2_: Objections to ArturJanc's suggestions?


<teddink> No objections

bhill2_: Ok. We'll prepare an updated charter, and submit it to the group for review.

Restrict window.name on cross-origin navigation

bhill2_: (We == dveditz and bhill2_)
... john_wilander_ you wanted to raise this?

john_wilander_: Right. This was discussed back in July.
... mkwst said Chrome could capture data on usage of `window.name`.

mkwst: I didn't do this. Sorry. :(

john_wilander_: We've started looking into this.
... Ran into test failures from W3C.
... Mostly around iframes that navigate cross-origin.
... Could be starting from unique going to non-unique.
... Embedder has named the frame, addresses the frame through its name.
... More concerned about top-origin navigation.

dveditz: Addressing frames through their name is one of the primary purposes of `window.name`, right?

john_wilander_: We started clearing `window.name` upon cross-origin navigation.
... Breaks some tests.

dveditz: Frames and popups, sites do that.
... At least they did 10 years ago.

john_wilander_: Were also thinking about restricting length or characters in the string. Currently DOMString.

<deian> I think it's still the case. Some folks working on FF (bholley and bz) looked at removing window.name. They may have some metricts from looking at this

john_wilander_: Initially, this was called out as part of the evercookie; if `window.name` is never set, it persists.
... Persistent tracker, etc.
... Also called out as payload mechanism for XSS attacks.
... Can dump JS into `window.name`, and then use it in the loaded page.
... Acts like an environment variable that can make it easier to bypass XSS protections.

dveditz: So if we made it read-only, `window.open()`, etc, that would help the first case, but not the second. And it may or may not break things.

john_wilander_: Yup.

mkwst: I don't think this is a bad idea, FWIW. I didn't add metrics because I didn't think about it when I was in front of a computer, not because I think it's bad.

john_wilander_: We might ship it into Safari's tech preview to get feedback.

<bhill2_> (mike, I'll take over scribing from this topic forward, thanks)

mkwst: I'm interested in hearing what y'all hear. :)

Restrict the loopback address to same-origin or Secure Contexts

Restrict CORS-safelisted request headers according to RFC 7231,

<inserted> scribenick: bhill2_

john_wilander: brought up at MtnView F2F, currently on a csp thread
... currently 4 safelisted request headers, of those only Content-Type has any restrictions on it
... that means a CORS requestor can add accept, accept-language and content-language with any characters in it
... reported when shellshock was a thing, to cross-origin send requests to servers with shellshock payload in it
... RFC7231 implies that the content should be restricted, but not what browsers implement
... we would like to enforce that

bhill2: any thoughts from other implementers?

mkwst: think the idea is generally reasonable, need to skim the thread for Jonas' concern
... seems he has issues with cors preflights generally
... notion of restricting values sent for a simple cors preflight is probably in line with the idea of a cors preflight
... limiting that data to protect unaware servers seems like a good thing to do, period

dveditz: sicking is concerned that networking team weigh in

mkwst: can we put on agenda for next call to make sure we follow up?
... get an opinion from Chrome side, Dan organize an opinion from Mozilla

<teddink> I will make sure that someone on our networking side is looped in - they should have an opinion.

dveditz: looks like Yoshino has an opinion, not sure Sicking is reachable

Restrict the loopback address to same-origin or Secure Contexts

john_wilander: started by looking at mixed content with local servers
... that want to do privileged things, mostly on desktop
... companion apps set up a local websocket server so extension can talk to local server, store things in crypto keychain, etc.
... dropbox has brought up that they would like to have some restrictions on this
... we treat it as mixed content, so an https page cannot talk to a local websocket but an http page can
... we would like to say that loopback address is actually secure and flip this

dveditz: we've already agreed to first point to treat as secure, and we are leaning towards localhost being localhost

mkwst: not only in secure contexts and mixed content and is in candidate rec that should move to PR at some point
... chrome has already shipped behavior that is accessible from secure contexts

crispin: can someone recap what happened in last call's discussion

<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/1652 https://www.chromestatus.com/metrics/feature/timeline/popularity/1653

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

mkwst: there are some metrics but only for dev channel at this point, will be more useful when they hit beta and stable
... ratio of secure to non-secure is about 1:1 on dev channel

<dveditz> Crispin: see link above (10/19) for last minutes

crispin: we had unexpected surprises when we tried this in Edge

mkwst: I expect it will be AV

crispin: we also hit cloud storage, DRM and CDNs
... so expect there are existing use cases that will be broken by this

john_wilander: are you saying a page served from http is making connections to localhost?

crispin: two years ago Edge made an attempt to do this, just blocked it
... a fair number of important partner organizations said we broke them
... they were using real local servers that they wanted to talk to

john_wilander: we have at least two password managers

Clarify worker-src goals

mkwst: suggests a few things
... 1. treat workers as scripts, not as child contexts
... 2. move worker-src to sit on top of script-src

<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/258

mkwst: think this is reasonable, anne asked for it a while ago
... other question is whether various types of workers should have their own policy
... or should inherit the policy of the page that creates it
... Brian's suggestion is that dedicated workers are scripts and should have the same policy

<mkwst> https://twitter.com/mikewest/status/798464142206087168

<deian> +1 in favor of these changes

mkwst: people have no idea what we are doing so there is opportunity to change it
... to me making a shared/service worker dependent on the context of the page that created it seems strange

<deian> I'm with you on it being strange. Though the suggestions for normal workers sounds good to me

<mkwst> bhill2_: Yeah, I think we went with this direction because it would be strange for shared/service worker behavior to be dependent upon the page that opened them.

mkwst: would be good if folks interested hop onto that github thread

Redacting ancestorOrigins according to Referrer Policy?


bhill2: <rambling summary of thread>

mkwst: think jochen wants to do minimal amount of work, not clear what that is
... if we could get a commitment from Firefox as to what they would ship, that would help
... emily wants to do minimum amount of work to call Referrer Policy done, move to CR and be done
... I think this makes sense, if we can come to a compromise that would be great
... fits well with what referrer policy should do, is a good idea regardless of Firefox shipping

bhill2: is pairwise compare OK?

mkwst: prefer that

<terri> +1 to moving it up one week for dec

<wseltzer> [Dec 14]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/02/15 22:32:51 $