Web Application Security Working Group Teleconference -- 29 Oct 2015

<trackbot> Date: 29 October 2015

<scribe> scribe: bhill2

deian: SOP/CSP/CORS are discretionary access control

<wseltzer> [Deian will share slides after]

deian: mashup use cases and data sharing cases are difficult with DAC
... libraries are over-permissioned, credentials are over-delegated and there are mashup scenarios we can't easily build between mutually distrusting services

<annevk> (window.location.origin should be document.origin)

dveditz: what stops a context from stringifying the data and postMessaging a string with no label

deian: there should be no definition for stringifying a labeled object

dveditz: would have to be opaque?

deian: there is a definition for how to structurally clone, which is to clone the label and then the opaque object
... have to use a getter to open the opaque object, which taints your context when used
... and who you can communicate with is then restricted

bhill2: what about navigating other contexts you have a handle to?

deian: you can't do that because of information flow policies

annevk: do you taint all the children?

deian: no.. mods to html5

bhill2: what about workers?

deian: only talk to workers through postMessage, so tainted

annevk: do you block push?

@@: how does this work with message ports? no concept of origins

deian: only allow sending messages when you know the origin at the other end

@@: but you can't know until too late

annevk: mostly have message ports for shared workers, apple just removed them, msft has no plans to support, and mostly never used - maybe they can go away

Mek: used to queue tasks quickly or structured clone things

deian: maybe can look and decide when receiving message, not sure where to specify that

thx wseltzer

deian: prototype was done in terms of CSP hooks

annevk: for navigation you need to hook directly into navigation to avoid traversing history

deian: maybe navigation source directive into CSP would make it a natural place to work

annevk: once you are confined you no longer have an active server connection

deian: yes, but it gets revoked once your confidentiality label changes

annevk: once you're confined, then things drop

dveditz: what happens to service worker? do you skip or drop if it's not an appropriate service worker?

annevk: might have to disable notifications, too, to avoid waking up service worker

deian: also, server-supplied labels for XHR

annevk: look at fetch since we've stopped adding features to XHR

deian: wanted to do this, but fetch made it awkward to look at response type to deal with labeled JSON

annevk: you can't extract an origin from a cowl:// URL, it is null / unique because that's not on the whitelist of schemes that have hierarchical authority

dveditz: we could add that....

some discussion w/dveditz and annevk about suborigins, not yet defined

dveditz: some way of making a suborigin look like a url would be useful

annevk: you could just compare literals

dveditz: if literals, don't make it look like an origin, maybe even reject anything with a colon

annevk: CORS just uses string literal

deian: was a reason to extract origin, to send servers you're communicating with your context information
... so for cross-origin requests, that is useful

dveditz: so this creates a leakage if you've blocked referrer
... like idea of signaling, because tells server more about how to answer a request
... but it also leaks information you may not want to leak across origins, need to think about it and get wide review

annevk: use of commas in header may be a problem

dveditz: doesn't need to be json, could just be WSP delimited
... what do brackets do for you? difference between AND and OR?

deian: yes, conjunction vs. disjunction
... header and js api has some mismatch- js api lets you specify in any format, but representation is always canonical ndis format
... firefox patch in the works
... also a subset we could do with a polyfill + CSP + 3rd party server

<mkwst> bhill2: It seems to me that suborigins overlaps.

<mkwst> ... Where does this fit in relation to that spec?

<mkwst> ... Suborigins are not about confinement, they want a public label for postmessage, normal cross-origin communication.

<mkwst> ... They need to be able to live as a top-level application.

<mkwst> ... Splitting out applications that happen to be deployed on the same domain without a synthetic domain.

<mkwst> deian: Disjunction does that.

<mkwst> ... No labeled cookies, etc.

<mkwst> bhill2: Seems like an explicit goal of suborigins that you could have localstorage and cookies and etc. Looks like a regular origin label.

<mkwst> ... Could have origin-labeled access to standard platform features.

<mkwst> deian: We could probably have some sort of labeled storage?

<mkwst> bhill2: Maybe suborigins are just the privilege part of this.

<mkwst> ... Privileges you expect. Reaching into other document contexts being considered cross-origin, etc. Doesn't imply navigation.

<mkwst> ... Would like to separate these concerns.

<mkwst> deian: Labels would do confinement, suborigins could do privileges.

<mkwst> bhill2: Header is the only way to enter suborigins, doesn't change state dynamically.

<mkwst> ... Forces isolation for the page from other things on the "same" origin.

annevk: what about permissions?

mkwst: "parent" origin permissions might cascade into suborigins, or it might be distinct - JoelW needs to decide this
... might need to ask users more often and store it internally - can't put any more info into URL bar, probably not putting suborigin there
... user would be confused why "google.com" keeps asking for permissions because the suborigin abstraction is not exposed

<mkwst> bhill2: Do I have to ask for permission every time for new disjunction states?

<mkwst> deian: Yes.

<mkwst> annevk: Since you're sandboxed, maybe the permissions are gone?

<mkwst> bhill2: You couldn't keep that up to date unless you were continually receiving messages from someone.

<mkwst> deian: But you couldn't receive messages unless you accepted the label.

<mkwst> annevk: Sensor API? Maybe you couldn't leak information that way.

<mkwst> deian: Open question!

<JeffH> http://www.chromium.org/developers/design-documents/per-page-suborigins

<mkwst> deian: If I have an iframe, I read something from somewhere else, I get tainted. But I still might have a handle to objects in the iframe.

<mkwst> ... Need to wipe out those references somehow.

<mkwst> ... Easy to do in Firefox.

<mkwst> ... Harder in Chrome.

<mkwst> ... Can we lock this to secure contexts?

<mkwst> dveditz: Yes. That's the whole point of that spec.

<mkwst> ... Browsers are generally moving towards locking things to secure contexts.

<mkwst> ... Only makes sense to talk about tainting if you know who you are to begin with.

<mkwst> ... So should require secure contexts.

<mkwst> deian: Future directions:

<mkwst> ... (More important to get v1 hammered out)

<mkwst> ... (Should talk to Joel to see what the overlap with suborigins might be)

<mkwst> bhill2: Yes. Would be nice if these were built on the same primitives.

Agenda bashing

containers

https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers

rbarnes: additional labels applied to contexts, local storage, etc. to prevent sharing state between e.g. two logins to Twitter with different accounts

dveditz: are these created by user or site?

rbarnes: user in current implementation
... when you load something in a container, everything is in that container
... effectively lightweight profiles
... in chrome each profile gets its own history, bookmarks, etc.
... containers only are for page created state, share user-created state

mkwst: interested in extracting some of the features out and giving them to sites, not just to users
... some projects in google are using chrome apps to get these properties

dveditz: firefox apps used to have that property and now they share cookies, etc.

annevk: because you don't want to have to login to Facebook 100 times

mkwst: but you do
... a site might not want to share by default that a facebook user is at the bank without that user's choice
... boils down to double-keying for all storage in a secure origins context
... tor browser has proven this is doable; breaks some things - if you opt-in, we can probably guarantee that it doesn't break things for those who opt-in
... loaded in separate process, subframes in separate process, separate cookie jar and all things I load use that new cookie jar, and identity is distinct in different embedding contexts even if same-origin
... only works in top-level contexts as a straw-man

dveditz: would this be site-wide?

mkwst: yes like hsts, with maybe a mandatory includessubdomain-like effect and locked to the topmost registerable domain
... like first-party only cookies. If you're embedded your embeddor has no power over you, no ambient authority associated with the origin in another origin's context

dvetditz: e.g. a womans' shelter might use this so embedded trackers can't know the user's been there

mkwst: private mode is different about not leaving traces locally....

rbarnes: this includes aspects of private browsing mode in terms of trackers, sharing, etc.

francois: primarily about preventing CSRF.

mkwst: primarily, but also if you know it is isolated it can be in a separate process, renderer can be hardened.
... might be a different way of solving some of the problems that EPR is trying to tackle
... example use case is to build as a web application, delivered through a browser, very sensitive things that are by-design not meant to be connected with the open web
... say, to manage virtual machines

deian: what if the browser tells the user about this...

dveditz: then we would be triple keyed

mkwst: in my use cases I care about there is no need to tell the user
... mozilla implementation requires user to know and decide what is sensitive
... different properties if a site can opt in

wseltzer: how does a user do something with isolated bank?

mkwst: if isolated bank gives you a means of logging in outside the isolated context, you can do what you want normally
... it might choose not to interact with you in those contexts

dveditz: firefox apps had this, chrome has this, tor browser is adding this

wseltzer: yes, but I think it is interesting and useful for the user to be able to interact with a site that declares itself this way

mkwst: interesting paper by Charlie Reis, et al. about multiple browsers
... epr is one implementation of an idea in there, this is another

dveditz: I like what david is trying to do with EPR but manifest seems icky

<wseltzer> http://www.collinjackson.com/research/papers/appisolation.pdf

mkwst: I suspect he will still want EPR

rbarnes: if we have a way for sites to opt out of containers, change or refresh container, overlaps nicely with clear site data ideas
... if all site data is containerized and you can throw it away...

dveditz: label containers?

rbarnes: hsts like semantics with max-age would create auto-expiring state

mkwst: would not want subresources to opt you in, maybe only from the root of the registerable domain

bhill2: can you tie this to a manifested web app

mkwst: easier to do at domain level because cookies are broken

annevk: you need a cache for this to persist the state

rbarnes: having a label might let different origins 'hold hands' in their own universe

bhill2: you can use a public key like android apps

mkwst: would like to think about it with regard to syntax

deian: I'd help write it up

wseltzer: can a user opt a site into this for themselves?

rbarnes: yes, it's already doing that, or could inject a header, or configure an origin by name...
... tor browser already doing this

timing attacks

deian: aware of researchers that can do these kinds of leaks exfiltrating data with SVG by blurring an iframe
... would be good to have guidance for spec authors on side channels and info leaks
... even implementations-wise, e.g. a cache is likely to result in attacks if it is shared cross-origin

COWL non-origin labels

deian: maybe namespaces?
... only thing that can mint privileges is the browser
... mint a.com and give it to a.com page
... but if we had something labeled geolocation: and we knew that only the browser could do that
... only kinds are unique or delegated privileges

dveditz: could have a colon if it had, e.g. a character illegal in scheme names to disambiguate it from scheme names, or a fixed name like cowl:, but would have to register it

annevk: need to be serialized to go over the network
... on network you could have a disambiguator when serialized, but object model would have different flags for origin vs. name

<rbarnes> annevk: filed Fetch issue: https://github.com/whatwg/fetch/issues/150

origin label; suborigin label - can't be minted by page; application label - can be created by any JS; "permission" label (result of an API call, unforgable); fresh

annevk: could we start out a lot simpler if we only had a separate instance of a service worker that we can give some labeled object it can compute on and return the result to its caller
... don't have to think about the interaction with as many things as browsing contexts
... for service workers we're also considering cross-origin cases, haven't explored that for normal workers
... thinking: a.com gives some data to b.com's service worker, b.com can't communicate back to b.com once it opens the labeled object
... could make the draft much simpler

deian: but today you have UI

bhill2: UI seems like most interesting case to me, provide experience to user of composite information but not leak that back to remote servers

deian: what to do when label provided by server doesn't match what it is allowed to provide?
... taking approach of not warning user about this

dveditz: should fail closed to the extent we can
... what if we just drop it, call it a network error

<scribe> ... new stuff nobody is using, we can check and be strict

mkwst: if we're going to be parsing, maybe extract this out to someplace where parsing happens

annevk: order matters, COWL before cookies

mkwst: have at least two blocks parsing CSP

annevk: that's because of service workers, but COWL is only right from the network
... can a service worker add these labels....does it do the right thing

deian: service worker would have to abide by confinement

mkwst: would that mean you can find where redirects go?
... if not-example.com returns labeled responses, I can read that cross-origin?

annevk: labeled data has to be CORS accessible
... there is a problem with confining service workers because they are shared
... to instances of b.com sharing a service worker, then a.com communicates with one in a way that introduces confinement, the other tabs stop working
... if you want fetching to work offline, going to involve service workers, and foreign fetch is coming
... so you'd have to have multiple instances of service workers

deian: may be able to think of service worker as extending the authority of the server and may not need to confine it

annevk: sw also has access to storage and other stuff

annevk thinks that chrome doesn't have wrappers, so existing references to a node in a different document that depended on being same origin won't be broken by setting the sandboxing flag

mkwst: true today, but not forever, eventually we will implement something like membranes...

annevk: maybe we should standardize membranes then...

AOB

<wseltzer> Melinda: We presented some work on DNS API previously; we've continued work and have Firefox and Chrome extensions

<wseltzer> ... work going into TLS after 1.3

<wseltzer> [discussion of uses of DNSSEC, additional information, isolation modes, supplementing CA info]

<wseltzer> bhill2: DNSSEC as a transport for policy

<wseltzer> rbarnes: also cache priming

<wseltzer> Melinda: Paul Wouters work

<wseltzer> ... establishing authority

<wseltzer> ... OpenSSL 1.2 implementation

- DRAFT -

Web Application Security Working Group Teleconference

29 Oct 2015

Attendees

Contents

Agenda bashing

containers

timing attacks

COWL non-origin labels

AOB

Summary of Action Items

Scribe.perl diagnostic output