Web Application Security Working Group Teleconference

<trackbot> Date: 27 July 2015

<terri> I wish webex had an obvious way to test audio before the meeting starts

<terri> but I'm glad it let me in 5 minutes early so I could test

[without the zakim identification, we need to present+ when joining the call]

<dveditz> (although I'm not sure the phone connection worked)

<dveditz> thx wseltzer, guess it's working

<dveditz> mkwst: are you using phone or the webex app?

<jww> I'm dialed in over the phone; is there anything I need to do to associate my IRC id with the number?

<jww> like we used to with Zakim

<dveditz> jww: I don't think there is

<dveditz> that's why "present+" for Zakim

<tanvi> trying to figure out how to dial in

<JonathanKingston> I'm call in however not tried speaking :D

<rbarnes> wseltzer: i am on webex, will dial in in a few min

dveditz: no minutes from last time yet
... on the agenda, suborigin namespaces concept

<JonathanKingston> Was CSP pinning not on the topic spreadsheet?

@@: should we talk about SRI failing open vs failing closed?

<mkwst> JonathanKingston: We (briefly) discussed pinning in Berlin, right?

scribe: I think decsion from Berlin was to bring it back on the list
... resulting in the suggestion to add CORS attribute automatically

<JonathanKingston> mkwst: super brief I guess, I don't have anything to add just asking as it was on the previous agenda :D

dveditz: we shouldn't decide on a call on which it was not announced

@@: we've had conversation on the list for a while; some of those people on the cal

scribe: we could decide on the call, announce on the list, and if people don't object, it's the decision

dveditz: but we usually announce agenda items in advance. on the other hand, this is minor
... add to agenda. Anything else?

sub-origin namespaces

dveditz: sub-origin namespaces and per-page sub-origins concept

jww: per-page sub-origin concept is logical extension
... Quick overview, then update on status, discussion
... basic idea, provide mechanism for sites to separate content from application
... while still serving both from same logical orgin (scheme/host/port)
... First question people ase, why do we need this?
... Practically, that's often difficult for real-world applications.
... google.com/maps google.com/finance are both logically separate apps, hosted on the same domain
... it would be nice to be able to separate them

<rbarnes> wseltzer: i am now on the voip audio

jww: Next question: why not sandboxes?

<rbarnes> yeah, my question is "why not domains"

jww: you can't have frmes in the sandbox
... you might want to share some state with the parent origin

<rbarnes> is this a problem for domains other than google.com?

jww: sub-origin is like "name sandboxes"
... original proposal: server would serve sub-origin name
... default policy, restrict everything
... mechanism yet-to-be determined to turn things on, geo, cookies, etc.
... another goal, users should not really deal with suborigins
... so geoloc permission hard to separate
... as we started looking, proof of concept, code in github
... then concluded this was almost certainly too restrictive to be useful
... What's the threat model?
... XSS attacker that can take over an origin.
... at foo.com /app1 and /app2
... you want attack that takes over /app1 not to be able to directly access content at /app2
... working internally at Google to find logical restrictions from app perspective
... especially for retro-fitting.
... Lowest-hanging fruit: CORS restrictions across sub-origins, figure out hte rest later.
... if we treat each sub-origin as requiring CORS, that would handle lots of cases
... in testing, treat requests from sub-origin as cross-origin
... some issues: how does it serialize, what goes to the server
... Wanted to present before we went much further. Thoughts?

rbarnes: In what sense are these origins "sub"? inheriting anything from parent, or logically separate?

jww: there is a relationship between subs and parent
... logical separation; there will be some state that should be shared

<rbarnes> it's origins all the way down!

jww: in my dream land, there are per-sub-origin options, but that would be up to the developer

rbarnes: can you comment more on use cases?

jww: started with specific Google apps; I've used other apps that look logically separate but hosted at same origin

devd: At dropbox, we'd love to use that
... separating by origins is less good, because the origin is what users trust
... like to separate off applications

rbarnes: seems the current proposal propagates the origin down the URL
... no binding between the resource being accessed and the sub-origin
... e.g example.com/app1 and example.com/app2 . looks as though I could send app1 for both

jww: we didn't want to tie directly to full URL
... we don't know a priori where the separation should occur
... the server is the authoritative source of namespace, via header

JonathanKingston: could this help with apex domains?
... without any subdomain?

jww: per-page, based on request
... to the same request URL, you coudl come back with different sub-origins

dveditz: browser can't make any origin decisions until it gets response from server?

jww: yes, that's been a challenge in design
... all requests from suborigin are treated as CORS-enabled
... trying to figure out if that's acceptable
... but later, need to do the pre-flight, etc. to determine if it's actually different

JonathanKingston: I've got some worries around top-level cookies

terri: can you talk about the complexity? what it means to have multiple origins?
... how big this can explode

jww: great implementor question
... open question

terri: we might need to understand that better before making everything a CORS request

devd: do we have alternatives?

jww: Anne vK had suggested we need that to happen everywhere (check origins on response)

devd: can we reduce preflight requirements? performance hit
... if it's same main origin, can we remove pre-flight, make access control on response

jww: I'll look into it

devd: how would this play with, e.g. service workers?
... those rely pretty heavily on origin boundaries

jww: you really don't want a suborigin to register a service worker
... but ok for the top-level to have superpowers, e.g. initiate sw that could serve to suborigins
... design goal of suborigins, to make the webserver the authoritative source
... one of the key invariants, a document can't enter a suborigin
... sw are "local representative" of the server
... so logical to control the suborigins

devd: if a suborigin tries to register a sw, what happens?

jww: it would fail

devd: I'd try to enable them; apps might want their own sws

jww: I can also imagine a world in whcih sws can be suborigin bound
... more complex

devd: how do local storage, cookies APIs work?

jww: only restriction CORS, service worker registratoin
... regular APIs acceptable
... since one of the big use cases is retrofitting
... but I'd like to have a world where you can start turning off and on APIs

devd: we have to restrict beyond XHR, eg. accessing iframes

jww: yes.
... the other major restriction is from js object perspective, suborigin is an additional part of the origin check re crossing document boundaries from js

devd: woudl be great to go through APIs
... CSRF cookie enough to do anything
... have you gone through these APIs to assess risk?

jww: we did one pass; considering threat of XSS attacker who takes over one app
... trying to get content on behalf of the user.
... does not include CSRF

devd: but sharing actions could be dangerous
... can you give list of APIs, and we'll help review?

terri: that sounds like something we'd want to document at CR

dveditz: ... how does suborigin concept compare with "web app" concept from WebApps WG?

jww: I'm not yet familiar with that proposal

dveditz: there seem to be large areas of overlap, and we wouldn't want to do both unless they're distinct

jww: which document?

<terri> It's not manifest, unless something's been added recently

mkwst: Jonas was talking about double-keying
... not sure which document

devd: WebAppSec is best equipped to create primitives
... and security boundaries

terri: when we were talking about security boundaries at TPAC, WebApps was interested in having WebAppSec do that

mkwst: value in creating primitives, and alos in talking about the higher-level concept we're trying to model

devd: for me it's very useful, modeling boundaries within app
... application concept seems broader than security boundaries

dveditz: what's next? are you going to extend your per-page developers design doc, or write the spec?

jww: depends on feedback
... dev's point re making sure we're restricting the right things
... a little bit more prototype, then spec

devd: prototyping on app side, developers using it

jww: I'm working with engineers too
... it would be extraordinarily helpful if anyone external wants to help

rbarnes: I'm a bit concerned that hierarchy will be confusing
... so separate origins
... rather than the origin + sub-origins

<rbarnes> 0, 1, many :)

jww: I'm not sure that it can't get worse

devd: I'd be sad if we didn't make new primitives cleaner than document.domain

gmaone: I share concern aboout not knowing in advance what will be the final destination of the request
... consider noscript
... concerned from security and implementation perspective

<dveditz> rbarnes: that would be terrible, would allow a super-domain to attack a child

<dveditz> (assuming they couldn't mess with dns anyway)

<rbarnes> dveditz: but the alternative is to have another axis along which origins can extend, which is also gross

<dveditz> yes

jww: a fundamental issue, you don't know until you get the response that it's cross-origin

<rbarnes> dveditz: if you're a child domain, the parent can always screw you

<rbarnes> nature of hierarchy

SRI Fail Open or Closed

@@: discussion on github issue

scribe: no one has expressed desire for fail-open

<jww> Here's the post-Berlin thread: https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0118.html

scribe: AvK had suggested that anything with integrity defaults ot cross-origin: anonymous
... do we go with implicit attribute or fail closed and force devs to add it?

@@2: I think editors agreed it should not include anonyumous implicitly

scribe: not universal consensus, but editors

<JonathanKingston> https://github.com/w3c/webappsec/issues/317

francois: I think so, perhaps Freddy has warmed to anonymous

mkwst: this is probably a breaking change

<dveditz> @@2 was jww?

dveditz: This suggests the ml thread is not yet resolved
... please respark that thread.
... Discuss on-list and put on agenda for next call.

<JonathanKingston> +1 thanks

[adjourned]

trackbot, end teleconf