Web Application Security Working Group Teleconference -- 28 Oct 2014

<wseltzer> [adjourned]

<trackbot> Date: 28 October 2014

<bhill2> Meeting: WebAppSec WG TPAC 2014 F2F Day 2

<bhill2> zakim aabb is [SalonB]

<rigo> scribenick:rigo

BH: scheduled until 16:15

Introduction:

-> see minutes from 27 Oct

BH: Presentation of the Agenda

Ein weiterer Ort an der Grenze zwischen Niedersachsen und Sachsen-Anhalt. 1958 wurde auf der Westseite in Zicherie ein Stein mit der Aufschrift "Deutschland ist unteilbar" an der innerdeutschen Grenze aufgestellt. Er steht heute als Gedenkstein in unmittelbarer Nähe zum Ortsschild des Nachbarortes Böckwitz.

<scribe> Agenda: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit

<bhill2> regrets, Mike West

survey results for rechartering

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/att-0159/SurveyMonkey_Analyze_-_WebAppSec_2014_Charter.pdf

Credential management API, almost consensus, two people volunteered to work on it

BH: give more structure so that browsers can make more out of password fields

http://mikewest.github.io/credentialmanagement/spec/

<bhill2> we are back...

<dveditz> we're back?

we're back

rechartering topics

Credential Management API

<bhill2> general agreement

<bhill2> JeffH has concerns about scope, potential impact of other efforts, e.g. FIDO, or related work

<bhill2> ... coming from WebCrypto workshop to replace passwords

<bhill2> he will respond on list

dveditz: should work on credentials to help with passwords

BH: client side is not compromising really data, but protecting server side data

tanvi: write only passwords (Lupin) iframe all of login forms and scrape them to see if secure
... http-page, write only type passwords

dveditz: argued against it for 10 years

BH: reasonable agreement to work on credentials

<dveditz> I argued against password auto-fill without any user interaction

BH: any objections

=> silence

BH: write only form elements will not be done

<dveditz> (because then an attacker can mass-harvest passwords potentially)

<tanvi> Automated Password Extraction Attack on Modern Password Managers, http://arxiv.org/pdf/1309.1416v1.pdf

BH: no-sniff, header X-content: no-sniff. Content sniffing rules that A.Barth worked on in IETF habe been picked up by WhatWG
... defined in mimesniff WhatWG, seems like already done in WhatWG
... no reason to duplicate

dveditz: everyone is using that, so why bother

<deian> tanvi: a more recent paper on password manaagers: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver

<tanvi> deian: thanks!

dveditz: mainly documenting what IE (invented) and chrome is doing already

BH: agree
... unanimous agreement to work on CSP next generation
... dom API, service workers, explicit about fetch etc.
... no objections in the room
... suborigins (joe will talk about it later)
... sandboxed cross origin workers, two votes against
... concerned about breaking google analytics and FB like button. But also vector for large scale attack. manipulating jquery e.g.
... we are addressing with subresource integrity, but also dynamic scripts
... difficult to apply subresource integrity to that. Interested in ways to secure here
... post message channel, well known interface. Much smaller attack surface. Web components is not taking that approach
... iframes are heavyweight. If include 30 of those scripts, it becomes to heavy
... perhaps create a worker, static interface that is identified with subresrouce integ. and some dynamic part

RW: perhaps looking into provenance

dveditz: interested in this, but not if it is duplicated elsewhere
... the thing I read tried to get around the iframe weight
... ECMA 6 or 7 will come up with containers

deian: we are doing something similar, container, context X, then extension components within this worker
... little bit more powerful than just ecmascript

BH: put in charter, script sandboxing

RW: STREWS is planning to work on sandboxing, so would be good to have it in the charter

BH: no objection, seems to be reasonable to work on

bhill2: WebCrypto Workshop, Virginie will summarize on Thursday. Some of it could end up here
... concerns about bringing it into WebAppSec because of the more controversial IPR around hardware
... don't want to derail CSP
... can follow on public-web-security for chartering

RW: good idea to have only a strong dependency

bhill2: yes, whether in WEb Crypto or new group, will insist on dependency
... summarizing the points for the charter... (too fast for scribe)

Presentation by Deian on Confinement with Origin Web Labels (COWL)

Deian Stefan introducing COWL

slides will be sent out later

Current status of COWL: portin to latest FF & Chromium

deian: how to do enforcement? CSP allows to control where context can disseminate data

ISSUE-69?

<trackbot> ISSUE-69 -- Consider directives to manage postMessage and external navigation of iframes -- raised

<trackbot> http://www.w3.org/2011/webappsec/track/issues/69

deian: COWL has intersection with issue 69
... creates a kind of reverse sandbox
... http://cowl.ws/

<bhill2> question: why not add this to the javascript engine for label propagation

ckerschb: label propagation, how to prevent an attacker to inject their own labels

bhill2: what about cover channels, side channels?

deian: once you enable mode, you get post message
... it is an opt-in system, doesn't break existing web

<bhill2> deian: difficult to use by programmers, don't need to label everything, get unlimited labeled blobs as needed (in response to last question)

bhill2: what is it look like for sites distributing widgets, third party to include your resource, make it as easy as possible

deian: self protection?

bhill2: yes, like button ... the ability to copy-paste a snip of javascript into pages

deian: this should be the case, the Lworkers does that. fundamental principle is data source is trusted.
... widget can always send to parent

bhill2: ship same app ot browser 8 (not support) and 9 (that supports)?

deian: you give up security as you can not know whether it works

bhill2: so have to understand the analytical message and react upon it

<tanvi> server knows if browser supports cowl

deian: yes, prot should tell whether supports COWL

MS: dozens of checks?

deian: dozens, being able to ??
... implemented a few larger scales

<bhill2> hi freddy, we are just doing some questions for COWL and will start shortly

bhill2: is this interesting stuff to consider?
... some sense of interest?

<bhill2> rigo: have you considered as a use case offline workers?

<bhill2> ... you don't want e.g. firefox os phone to leak your address book only because it can

<bhill2> ... in this case the labeling has the function of protecting user-centric info

<bhill2> ... but how to your provide an interface for the user to manage privileges

<bhill2> ... e.g. to prevent an app from phoning home

<bhill2> deian: if you as a user are using e.g. facebook, you're specifying a policy about who can view your information

deian: thought about phones, but were mainly concentrating on server side

<bhill2> ... we can label that information through app UI interactions

in context of offline applications, lables are easier

<bhill2> rigo: if I am an attacker, I would say if I temporarily disallow phoning home, can I hide the information I want to leak and wait until the restriction is over

<bhill2> deian: if you store things, the mandatory label persists, so it is re-applied when it is read again

<bhill2> rigo: so there are additional requirements on, e.g. local storage

<bhill2> rigo: have you thought about abusing restrictions? block everything X?

<bhill2> deian: whoever you send data to, they have to decide to unlabel it themselves.

<bhill2> ... labels can only be raised by the context, not by another context

<bhill2> rigo: can I create e.g. DRM to e.g. prevent copy/paste?

bhill2: very interesting discussion, first time we have seen it, have to bring it to the list
... any strong objection to include it into the charter discussion

Dan: we had already lightweight isolation etc..

bhill2: should we consider this under "lightweight sandboxing" have some more on the table, COWL would be added to the list

Melinda: yes, just add

JeffH: yes, but not DOM manipulation

bhill2: some agenda discussion; Suborigin proposal

<inserted> scribenick: bhill2

Joel Weinberger introducing SubOrigins proposal

jww: we have the origin security primitive in the browser
... sometimes you can't create a new origin just to make something untrusted

<rigo> JW: often different things into the same origin, but need different levels of security

jww: would be great to be able to split things into smaller origin pieces
... e.g. google.com is search, google.com/maps is a very different application
... that is on the same origin for historical and other reasons
... but has different security properties, etc.
... would be great to be able to treat them as different principals
... proposal allows creation of arbitrary namespaces for applications

freddy - better?

<freddyb> bhill2: much better. thanks!

<freddyb> also thanks to jww for repeating!

devd: dropbox would be very excited to use this

jww: current proposal is a csp header with a tag for what suborigin you want to enter
... gets represented as an addendum to the scheme
... e.g. plugins have own way to deal with origins, would be nice to not have to rewrite that by putting into current origin token architecture
... this is basically named sandboxes

<freddyb> I wonder if there's overlap with scopes (existing in serviceworkers, manifests) and cookie path limitations ;)

<wseltzer> [start again in 10 min]

Subresource Integrity

<inserted> scribenick: deian

<wseltzer> [resuming]

<bhill2> http://w3c.github.io/webappsec/specs/subresourceintegrity/

bhill2: want to check in SRI, since there are news. what's going on? and let's look at

devd chrome has an implementation, we'll take a look. most people seem happy with the spec. same goes with the community

devd if anything we should be doing more

joel big question: https and http. should it apply to http?

two half: should SRI run on non-https pages. can you even make an integrity attribute? can you have integrity attribute to http content?

dveditz: not sure why you wouldn't want to do http. we don't want to relax MIX; as integrity guarantee why not allow it?

joel: integrity should not be allowed to run on insecure origins; i think we should ignore the integrity attribute since it's meaningless and attackers can modify

tanvi: not serverside attacks, only MITM

<freddyb> it's only meaningless in the face of _active_ attackers, not passive attackers (i.e. reading)

<freddyb> I agree with what I think I heard dev saying (that it still protects the compromised CDN case on plain http)

dveditz: i know we're trying to encourage tls, but it seems mean to not include http

joel from our perspective it is a little questionable on how you present this to developers. dveditz it's same as http content, so most of the time you get what you expect.

joel SRI gives you integrity, but it's not clearly useful since attacker can modify it.

dveditz: if things keeps getting breaking because of no https, then devs will lean to use tls

joel: if you have a MITM attack then you can just serve content with proper integrity attribute

should webcrypto occur on http?

can't do it in any meaningful way for http

bhill2: load resouce but not check integrity?

dveditz: two choices: not load resources OR spit out console message and say wheneter or not you checked the integrity

freddyb: not sure i got everything, but as far as i understand: heavily agree on MIX: should not relax this

on the other hand, afaiu not sure if we'll reach consensus on http vs https, maybe take offline

original question: i think it's a good idea to go forward with scripts only for now. seems like the most meaningful way to go forwar

joel: i would suggest style as well, but script is definitely the priority

<wseltzer> https://www.w3.org/wiki/TPAC2014/SessionIdeas#Trust_and_Permissions_in_the_Open_Web_Platform

wseltzer: dave ragget suggested (on truste & permission) and I'm looking to collect from dif places to address similar problems in similar ways. so if you're seeing this in other places, let me know. and if others (chris palmer started a thread) are itnerested please bring them in the discussion

bhill2: we have a subset that is not controverisal that people want to use now. there is the other subset that is controvertial. should we prune out the latter?

ship the first (level 1) and work on the second at a different pace

joel: seems like a good idea, given that even at google we can't reach consensus on the controvertial

bhill2: no relaxing of MIX warning. script & maybe style

what about object source?

devd not sure what the use for object src is?

bhill2: same as script

devd: concern for compatability. too many things that happen with object to deal with it now

<tanvi> downloads?

dveditz: would love to do it, but in practice it's hard. devd: sites can use CSP to restrict objects for now

bhill2: what about downloads?

tor exist nodes backdooring exe files. lots of download sites. unfortunately this brings back the http vs. https issue

would be nice to apply integrity to it

not the same threat model since it's not part of the DOM, but the threat model is worse

devd: what's the mixed content story for downloads?

tanvi: we block http downloads

<tanvi> well, not exactly

tanvi: depends, e.g., if it's iframe we block, but if you navigate it's okay
... ^ does that capture ti?

<tanvi> yes :)

devd seems like a great case for using SRI for http. tanvi: download whole file and check integrity?

devd: browsers download then raname, we would check integrity before rename

joel: there were a bunch of issues that were raised wrt to this
... controvertial in chromium team, but encouraging http downloads since we have integrity may lead to less https

mnot: what's the proposed experience when integrity fails? devd: same you get today: this may be malware

<freddyb> but integrity is not authenticity. I'd hope we could argue that "good" websites would really want to strive towards both (and the latter is only viable through HTTPS?)

<freddyb> ..thinking that integrity wouldnt really discourage https

because this imposes on author to keep hashes up to date, this may result in many false positives. may lead to people switching browsers. bhill2 what about user copying link and pasting it into addr bar

joel: UAs can make it harder to copy URLs that have integrity attributes

already do this for javascript:// urls

bhill2: doesn't have to have the malware warning

joel: we sould adjust according to what we see in the wild [that is the false positives]

bhill2: how do we reduce the click throughs? can keep iterating on this

mnot: ssl configuration is one problem. this is an authoring problem and I wonder how this would work out

bhill2: even if page is maliciously modified, some users will get around it

tanvi: seems like MITM is a bigger threat.
... in 1st version, what if we keep it ambigous about http? joel: certainly okay
... for downlaods, i see a reason to keep it to https only, but for js not so much since there are so many examples of people pulling content from http places

bhill2: the attacker cost to compromise jquery cdn is smaller than everybody on https. mnot: devs have to be careful when they use SRI, since e.g., flicker may change source e.g., due to bugs

tanvi: how do we handle versioning?

how should sites deal with changes?

joel: is SRI useful? devd: we can give multiple hash values. if file names remain constant you may supply current, old version of hashes

if filename has part of hash, this is a solvable problem

bigger question is to ask jquery about this kind of versioning problems

we can run experiments for a few months and see how things go. we don't rely on latest version of jquery, we rely on specific version, so hashes just gives you more

joel: try to load latest from cdn, but if it's not what you expect, but you can load from your site

deian: what about signatures? bhill2: shakes/has seisure

<freddyb> are we going to replace an integrity problem with a key-sharing problem?

<freddyb> ;)

<tanvi> ;)

problem with signatures is that it doesn't really change the threat model and adds lots of complexities

<wseltzer> there is interest, now with webcrypto...

JeffH: +key management issues

dveditz: there is an xml signature proposal

mnot: we're interest in solving this and more general problem. though we talk about it at a transport layer where you have another identity. use case: im a bank, but don't trust cdn with everything (only with certain things)

<freddyb> (with SRI relying on CORS-enabled resources, one could do XMLHttpRequest to fetch, webcrypto to verify and blob URIs (=same origin) to load)

dveditz: lots of places where signatures are needed, but webappset is not the right place for this

jeffh: I'm imaging this useful/deployable with server side support. I have this web app, on the server side I check all the deps and compute the hashes. On the server side I can make sure that whatever I spit out to the client-side is correct

<wseltzer> [another use case is the user has out-of-band assurance at one point in time, and wants to pin that]

<tanvi> (i'd like to talk about caching when we have a chance.)

mnot: link headers/manifest seems like an alternative approach ...; bhill2: we're probably going to split spec into 2 specs: content addressable vs. the less controversial; devd: we have objections to objects, joe wants styles (maybe not so bad), but anchors and downloads are uncontrovesrial

billh2: it's worth trying (that's what we mean by uncontroversial), and see if it works/if people can put it to use

mnot: talk about or implement?

bhill2_: implement it enough and actually learn from how people use
... we can speculate on how people use this, but i don't think we know until we put it out there and learn from data

JeffH: when you say object you mean <object>? dveditz and applet and embed tags; bhill2_ stuff covered by object-src

in csp

mnt: is it worth to talk about this in ters of fetch?

dveditz: spec is written in terms of fetch

bhill2_: mostly specified as monkey patch to fetch
... lots of good reasons to specify in separate document. may have mutual dependencies. certainly we're going to need to figure out hot to normally reference fetch
... download is still controversial in terms of how it should work and how we should do it? dveditz controvertial in how you present it to people. devd browser vendors should decide this

joel: it is controversial in chrome to do http downloads. dveditz because of the http part from https? should we do downloads? joe: yes

devd its far more like that you have a download from http url on an https page

mnot: problem is that people publishing link and actual download are different people

what should we warn on? how will people react?; tanvi: if we put leave it ambigous then that would solve the problem for chrome too

jeol: we would be happier if everybody did secure downloads, but sure

devd: if chrome and ff differ on this part it's okay according to spec

bhill2_: how much will the cut simplify the spec

joel: it cuts out all the cache stuff, that's huge

<freddyb> we did not talk about reporting!

<freddyb> happy to leave it out for now, just remembered.

<dveditz> is there reporting in the spec?

<dveditz> I missed that

<tanvi> reporting is important to alert websites about third party libraries that have changed withotu their knowledge

<freddyb> dveditz: there is. http://www.w3.org/TR/SRI/#handling-integrity-violations-1

<freddyb> tanvi: in theory, you could get it from logs through the fallback mechanism

<dveditz> freddyb: what section?

<freddyb> dveditz: 4th paragraph this 3.5.4: "MUST repor a violation"

<freddyb> report*

devd: how painful the non-cononical src would be to implement?

<bhill2_> 3.5.2 in the editor's draft

<bhill2_> noncanonical-src attribute

dveditz: don't really understand why we would use the noncononical-src

if the source would change the you would fallback on your slow secure server

said tanvi

devd: simple enough attribute that we should do it

dveditz: I will ask; joe: I think it's complicated, but if we see enough value we should do it

<freddyb> +q

<freddyb> i.e., if (typeof jQuery === "undefined") { // create script node + same-origin jquery URL and add to DOM }

freddby: was wondering if you really want an authenticate same-origin version of the reource. what about: if jquery is not defined, the use shim to load from secure source? not saying we shouldn't do it in the spec; joe: interesting point: should we be defining what it means to fallback or is that application specific. tanvi: that makes it harder to implement apps

if it's cross-origin content: I can't take hash

tanvi: if we take noncon.. and ask devs to write own code to handle fallback, the adoption would be much harder

devd: i think devs already do this since they don't want to rely on jquery cdn to stay up

joe: if we don't offer it then we'll never know. devd: should this be in level 1 spec or level 2 spec. joe: I don't think it's controv, but it may be hard to implement

<freddyb> SRI requires cors-enabled though, which means you _can_ compute a hash manually.

dveditz: if you load nonc.. do you still check hash? bhill2_: no, it's a fallback & trusted
... I don't know it sites will use this; joel: proposal: rename src and backup-src
... src has to be what normally gets loaded

<freddyb> I too dislike "noncanonical-src" as an attribute name. "src" & "fallback" seems more intuitive.

joe: will update spec to use better names; tanvi: does fallback perform integrity check? devd: no, since the fallback should be for something that definitely works

<wseltzer> [have we ever done a privacy review of the various reporting options?]

dveditz: from the text it seems like report doesn't block so we should rename to report-only.

devd: spec needs editing

tanvi: how should reporting work? dveditz: piggy back on csp. devd: could trigger JS error

bhill2_: to wseltzer's question: we had external people look at it and it doesn't leak any addition info. dveditz there was an issue with reporting and redirects, but we fixed the spec; joe: it's been ad-hoc

wseltzer: bookmarklets could hook on to reporting to drop reports

dveditz: need to make sure that sites don't learn about what add-on's you have instaleld

tanvi: what about caching? if same resource is fetched from two sites. joes &devd: we're going to punt to level 2

wseltzer: thanks :)

bhill2_: to summarize 2 sides: this is not making anything worse, it's strictly making things better. dveditz if we load things by hash then we could have cache poisoning attacks and attribute attack to wrong person

devd this is a big can of works, let's just focus on level 1 and deal with rest later

bhill2: if you identify exact content. where it comes from doesn't matter. joe: there were lots of questions about caching headers, which I think is more controversial.

consnus on the pruning and working on the less controversial first

bhill2: there is an proposal to expose dns info to the browser. might be useful to have this group of people to look at this and evaluate what could possibly go wrong & tell them not to do certain things even if we don't consider it at webappsec; wseltzer this is from versign who want so to be involved. we should work with them and see what can be improved

<freddyb> thanks for taking notes, deian

<wseltzer> [lunch break]

<freddyb> it helped a great deal in syncing the audible bits into something meaningful \o/

freddyb: glad it helped, sorry for missing things :)

<freddyb> this raised hands here \o/ are unrelated to your lunch/afternoon plans

<freddyb> enjoy lunch, people!

<wseltzer> [now really adjourned]

- DRAFT -

Web Application Security Working Group Teleconference

28 Oct 2014

Attendees

Contents