WebAppSec Face to Face, Day 1, TPAC, 1-Nov-2012 -- 01 Nov 2012

<bhill2> https://www.w3.org/2002/09/wbs/35125/TPAC2012/registrants#WebAps

<bhill2> for folks hoping to dial in, my apologies

<bhill2> I got the offset from UTC wrong in scheduling the call, so our bridge won't be available until 11:00 am local time

<bhill2> trying to get tomorrow's call time adjusted

<bhill2> we may try to move some of the UISafety discussion agenda time to tomorrow afternoon

<bhill2> to accomodate Giorgio's participation, as I forgot that today is a holiday in Catholic countries

<bhill2> but we will keep the Accessibility discussion, at least, on today's agenda

<bhill2> looks like Giorgio won't be able to make it in any case, so we'll leave the schedule unchanged

<ekr> scribe ekr

<ekr> bhill: major issue with testing/CORS is identifying what coverage we have and what features may be at risk because of test coverage

<ekr> bhill: there is a CORS fork in WHATWG

<ekr> ... want to discuss how to deal with this.

<ekr> dveditz: what's the reason for the fork?

<ekr> odin: Anne was unhappy about the Invited Expert agreement.

<ekr> bhill: only substantive change seems to be changes to references in WHATWG spec.

<ekr> ... best strategy may be to discuss the changes with him.

<ekr> ekr: which specs do the vendors intend to follow

<ekr> odin: we usually follow the most updated specs.

<ekr> bhill: I don't think we should drop this. It's part of our package.

<ekr> correction to above: there is a change to referrer handling

<ekr> bhill: let's ask Anne about that.

<ekr> ... does Mozilla have anything to say about which set of specs they intend to track.

<ekr> dveditz:we would expect to follow the CORS spec, but if there is an updated spec in another standards body, we might follow that?

<ekr> bhill: so we would need to decide how to handle future updates

<tanvi> can we have a link to the fork?

<ekr> [discussion of whether we can take this material]

<ekr> ekr: what is the IPR status of this contribution

<bhill2> GitHub link to fork of CORS

<ekr> bhill: there is a mechanism for independent contributions that aren't invited experts.

<ekr> ... so maybe we can get such an agreement in place when there is a fixed list of WHATWG changes.

<ekr> odinho: this is happening with a bunch of other specs as well.

<ekr> bhill: let's start by asking Anne what he is doing with other specs and then we can follow up with W3C staff

<ekr> ... we had a set of objections to CSP on the basis of privacy

<ekr> ... post-LC comments about reporting mechanism as a back channel and feature reporting as a fingerprinting vector.

<ekr> ... we had consensus in the WG but I hosted a plenary session yesterday to forestall external issues

<ekr> .... will post my presentation

<bhill2> http://www.w3.org/wiki/Fingerprinting

<ekr> ... basic idea was to establish a set of guidelines for these discussions

<ekr> ... background for privacy interest group on the security community's assessment of the situation.

<ekr> ... with the hope that their guidelines will take into consideration meaningful threat modelling

<ekr> ... hopefully will give us better framework for the future.

<ekr> ekr: some people may not be entirely convinced

<ekr> dveditz: there was that other guy who wanted to have reporting on user-agent injected addons. I'm less sympathetic to tht

<ekr> dveditz: edward's problem is something we should address

<ekr> dveditz: ingo chow wants to report on add-ons to see if someone is trying to target his site

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0069.html

<ekr> dveditz: concern is a malicious add-on adding scripts

<ekr> ... but in that case it could probably turn off CSP reporting

<ekr> ... from a privacy standpoint it's not the server's business

<ekr> ... what the client runs

<ekr> bhill: an issue of priority of constituencies

<ekr> ... what about an add-on that injects ads

<ekr> ekr: it's the user's browser

<ekr> bhill: example of intermediaries injecting ads, rewritign scripts, etc.

<ekr> odinho: add-ons are effectively part of the browser and shouldn't be influenced by comments

<ekr> dveditz: we haven't fixed mozilla with addons reporting

<ekr> ... would like an add-on that injects content in the CSP page should be able to override CSP but should have to explicitly do so.

<ekr> bhill: should add-ons be able to disable reporting

<ekr> ... can do it by brute force method

<ekr> odinho: absolutely.

<ekr> dveditz: you can always suppress it some other way

<ekr> bhill: to wrap up the privacy thread...

<ekr> ... replies from dveditz and mike west that it's not CSP's job to police extensions

<ekr> ... is this something we want to resolve as the WG

<ekr> odinho: maybe in a FAQ

<ekr> bhill: there seems to be consensus in the WG.

<ekr> dveditz: it's a statement on behalf of the server to enforce a policy, not a binding rule

<bhill2> proposed resolution: The priority of constituencies followed by this WG is that the user is in control of their user agent, and CSP is not a mechansim to allow resource owners to override user preferences or policy on how resources are rendered/modified/etc., including by user agent add-ons

<bhill2> so resolved

<trackbot> Sorry, couldn't find to. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

<bhill2> action bhill2 respond to ingo chao on official WG position re: csp policies for add-on modifications to resources

<trackbot> Created ACTION-82 - Respond to ingo chao on official WG position re: csp policies for add-on modifications to resources [on Brad Hill - due 2012-11-08].

<bhill2> we are taking a 30 minute break

<bhill2> reconvening at 11:00 local time

<bhill2> next agenda topic: CORS and WHATWG fork of "Fetch", guest speaker annevk

<bhill2> call bridge is now open

CORS and WHATWG fork of "Fetch", guest speaker annevk

<annevk> http://fetch.spec.whatwg.org/

<annevk> https://github.com/whatwg/fetch/commits

<inserted> scribe: bhill2

annevk: Last-Event-ID, etc. should not be on the simple header whitelist
... it is about what developers can set, not what the spec can send

dveditz: clarify developers in above comment

annevk: developers are web content developers, web UA developers are "implementers"
... diagram is buggy, should include "send"
... hello world arrow at end should go all the way to dotted line
... access check happens in network library, not in the XHR
... long term plan is to integrate it with HTML fetch algorithm
... just going to wait for implementations to stabilize

<odinho_> Draft of a very simple CORS overview

annevk: fetch handled by network layer
... referrer source was feedback from mozilla about fetch algorithm
... in some cases didn't like the header the algorithm would come up with
... introduced concept to pass through explicit referer to override what would normally be computed
... in certain cases you can make a choice what the appropriate referrer is
... wanted ability to do explict setting
... is an algorithm in a specification that invokes fetch, but control is not given to web developers

tanvi: this is for a resource to check referer when servicing a request

annevk: this is to indicate what the referrer should be for the user agent
... it could be a script that invokes the XHR, or it could be the URL associated with the XHR object
... could be invoked from another resource accessing using SOP
... referrer includes path,etc. so might be different, even if Origin is the same

other changes are 308 status code

dveditz: should do this as it is a legitimate code

annevk: yes, other browsers do this too in other places with redirects
... in practice all 3xx are not handled, need to be explicit in what ones should be
... only two major changes, a typo fix, added julian and phllip to acks
... no outstanding bugs that would cause changes to fetch algorithm
... hixie and I want to wait on further work on fetch
... to merge it with CORS, but that is 4 years down the road
... there is one thing where developers complain, want more flexibility with access-control-allow-origin header
... is * or a single value at the moment, maybe should be comma separated value for static resources with multiple consumers
... need to set vary header today, lots of problems with that, proxies, etc.

jonas: if it's a static file, why would you want to protect it?

annevk: font people are complaining because of licensing issues

<odinho_> [ discussion about dynamic vs. static ]

devditz: concerns with multiple headers could easily be addressed by resources that care

jonas: one of original concerns was that adding multiple would lead to introducing patterns, etc.

annevk: don't want to add regexs

jonas: one other problem: at time of making request, need to know if in CORS mode or not when initating fetch algorithm
... when you load script elements would like to do fetch without CORS headers without declaring in advance

annevk: that exists today
... no CORS, anonymous, and cross-origin modes
... want to use "potentially CORS-enabled fetch" algorithm

odinho: has a no-CORS path

<annevk> http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch

annevk: doesn't work as I thought

jonas: only place it is useful is script tags

annevk: images too

jonas: for images, either going to use image or not, if you need it, need to set CORS anyway

annevk: either way, change would be in fetch algorithm, not in CORS

odinho: also in track, for subtitles

annevk: only outstanding possible change is comma separated origins

dveditz: need to see if browsers would take that change

annevk: shouldn't be a problem, browsers don't object
... origin spec allows space-separated origins
... I think this is a bug in origin, tried to errata, but errata process doesn't apply to changing spec semantics

odinho: likely to result in bugs from users that just match a string

jonas: worried this will affect fonts, mozilla is only one using CORS for fonts
... didn't realize that origin is changed to null on redirects, breaks fonts

annevk: needs to set * in that case on the resource

dveditz: reason origin spec had a list was interest in using it as an anti-CSRF spec

annevk: but implemenations differ, webkit is consistently null
... allowing choice, as is done in origin spec, is bad
... servers can't rely on it then
... is worth pointing out in the syntax that the null behavior is explicitly specified as the behavior vs. the multi-origin option in Origin spec

dveditz: asymmetric to do multiple values for servers, not for redirect from client

annevk: best chocie is to get patent committments and go all the way to Rec quickliy
... can go directly to PR if we have evidence of implemenations
... a year later we can incorporate any updates

bhill2: only concern here is that we have knowledge of implemenations so we can know what is "at risk"

odinho: only know about opera, have implemented everything in spec, hopefully is correct and no omissions

gopal, are you there?

<gopal> yes

based on your knowledge of tests, any features at risk?

gopal: hard to comment on that, will address in next agenda item
... lots of tests, hard to associate with what parts of spec the tests cover
... syntax elements from section 5 have lots of coverage, but not clear, should walk through tests to identify at risk items
... can go through analysis in the afternoon when returned from lunch

bhill2: will do that after lunch, go directly to PR if no at risk features

gopal: allow origin header currently says origin list, but below says single origin, star or null

annevk: that's true, why I tried to file errata
... already a note under access-control-allow-origin, syntax is constrained by resource processsing model and what browsers check against
... so no changes needed there
... confusion was whether this was a list of servers allowed, when really it was a redirect stack

odinho: parser in spec is future compliant

annevk: would be good to update to allow more than one access-control-allow-access headers? need to do ua sniffing anyway for future compat

odinho: if current impls read only first value and ignore later

annevk: still broken, need sniffing

annevk; main problem is caching and broken proxies wrt: vary

scribe: don't want to cache three versions of a font because of access control variance
... proxies and caches need to deal with that situation already
... don't know how much it impacts real world
... if current is broken, would have been for a long time, haven't heard screaming
... would just leave it as-is until complaints grow

bhill2: then let's stabilize, stabilize test suite and try to go to REC

annevk: text i s all consistent
... want want to prevent other specs from using a space separated list of origins representing a redirect stack in the origin header

dveditz: shouldn't have multiple values in Origin header for redirects

annevk: would prefer to obsolete optional behavior in Origin RFC
... all API specs have to hook into fetch algo so in practice not a problem

adjourned for 2 hours for lunch

next agenda topic is detailed test coverage review of CORS, identification of any at risk features or features for which we lack enough coverage to decide on at risk status

<gopal> yes, they are supposed to be there at 14:00

<ware> Still waiting for everyone to get back from lunch.

<npdoty> I'm Nick Doty, W3C, working on privacy across our standards

<gopal> http://w3c-test.org/webappsec/tests/testRunner/

CORS test status

<dveditz> gopal: we still need a lot of acceptance tests

<dveditz> … sections 1,2,3 and 4 we don't need coverage

<gopal> 1. not required

<gopal> 2. not required

<gopal> 3. not required

<gopal> 4. not required

<dveditz> … the most important sections to cover are 5.1-5.9 (various response and request headers)

<gopal> .1 basic.htm, credentials-flag.htm, errors-async.htm, request.htm, simple-request.htm

<gopal> 5.2 credentials-flag.htm, request.htm

<dveditz> … several tests already go through some of the headers

<dveditz> … but we need consolidated set of pass/fail tests for each specific item in the spec

<gopal> 6.1.1 5.1

<gopal> 6.1.2 5.2

<gopal> 6.1.3 5.2

<gopal> 6.1.4 5.3

<dveditz> … section 6 is a mapping to headers in section 5.*

<odinho_> ScribeNick: dveditz

… tests for section 7 also have correspondence with tests for sections 5.*

<odinho_> Scribe: Daniel Veditz

odinho_: we need to document the mapping and that eventual consolidated tests cover the specific section 5.* feature and also the mapped section 6 and 7 texts

… browsers cache responses which somewhat invalidate the tests

… need to aggressively bust caching for valid tests

the previous two lines were odinho_

bhill2: thanks for the summary, sounds like we've made a lot of progress. Is this something we should work on today?

gopal: setting up the test environment is pretty easy, if you need help gopal can help with that
... hard to tell what parts are at risk from the current tests
... once we start putting it together [i.e. mapped to specific test sections] it will be clearer
... some people from Mozilla pointed out test errors but also provided fixes which will increase success percentage
... need help going through the failing tests looking for errors

DanD: is there any way to set up the test environment without having to hit the w3c test environment?

odinho_: brad set it up a VM that runs standalone, and odinho_ just runs his own instance of apache

<gopal> to test locally: use VM image from Brad or set up /etc/hosts with w3c-org in your local environment

<bhill2> http://dl.dropbox.com/u/76057758/WebAppSecTestsuite.vdi.bz2

<bhill2> That is the latest VM image. Sun VirtualBox image of an Ubuntu, all free software

<bhill2> user/pass is webappsec/webappsec

<bhill2> that link seems dead

<bhill2> https://dl.dropbox.com/u/76057758/webappsecVM.tar.bz2

bhill2: use the second one
... I was talking to some of the organizers of the "test the web forward" group to see if they'd like to sign on to maintaining this environment
... (for more than just webappsec tests)

gopal: brad, are all the recommended w3c ports enabled in that VM?

<gopal> port 80, 81

bhill2: I didn't realize that, that's one of the reasons it would be good to have a dedicated person to maintain this

<bhill2> action bhill2 to update port numbers on apache for test vm; 80-83

<trackbot> Created ACTION-83 - Update port numbers on apache for test vm; 80-83 [on Brad Hill - due 2012-11-08].

gopal: so if you see test failures you need to set up those ports

<gopal> W3C Web test server exposes the following domain names for testing purpose as of 2011-06-07:

<gopal> http://w3c-test.org/

<gopal> http://www.w3c-test.org/

<gopal> http://www1.w3c-test.org/

<gopal> http://www2.w3c-test.org/

<gopal> http://天気の良い日.w3c-test.org/

<gopal> http://élève.w3c-test.org/

bhill2: is there anything further to do today to identify tests that need updating?

gopal: we can take that offline and see if there are any other topics to discuss here

bhill2: I mentioned "Test the Web Forward", because testing is the main step to get from CR to Recommendation
... for Cors and CSP. Will be a challenge for the UI safety proposals since testing ui events like clicking will be trickier to set up

odinho_: met up in Paris, a lot of developers came. First day "how do you test the spec, how do ref tests work"

… had some lightning talks also (odinho_ gave an indexedDB talk, for example)

… different experts were there on different topics, sat down and wrote some tests.

… 404 tests written that day

… CSP is a little harder because of the netword requirements, HTML tests easier

… creating CSP tests would work well in a setting like that

… first was in San Franciso, next in Beijing, most recent in Paris, doubling the number of tests written

bhill2: need to create a harness for sending UI events, then can copy that into multiple tests

<bhill2> odinho: chrome, opera have webdriver, moz has marionette which will be web driver when it's finished

bhill2: Giorgio is working on a standalone version of ClearClick
... would be nice not to need 5 different versions of each test for each driver/browser
... what are next actions?

gopal: create list of acceptance tests, especially those related to section 5.* collected in one area

bhill2: want actions in the tracker so we know what's left and how we are progressing

<bhill2> action gopal to create acceptance tests for section 5

<trackbot> Created ACTION-84 - Create acceptance tests for section 5 [on Gopal Raghavan - due 2012-11-08].

<bhill2> action gopal to create acceptance tests for section 6

<trackbot> Created ACTION-85 - Create acceptance tests for section 6 [on Gopal Raghavan - due 2012-11-08].

bhill2: wanted to create some actions here, assigned to gopal by default but encourage other people to take some of this on

<bhill2> action gopal to create acceptance tests for section 7

<trackbot> Created ACTION-86 - Create acceptance tests for section 7 [on Gopal Raghavan - due 2012-11-08].

<bhill2> action odinho to fix transient CORS test failures due to caching

<trackbot> Sorry, couldn't find odinho. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

gopal: someone from Mozilla pointed out errors, we need to reach out to see if they're ready to contribute that

<bhill2> action oomdal to fix transient CORS test failures due to caching behavior

<trackbot> Created ACTION-87 - Fix transient CORS test failures due to caching behavior [on Odin Hørthe Omdal - due 2012-11-08].

<bhill2> odinho: there is a meta help header that allows linking of test cases to the section they test

<bhill2> gopal: that's great, allows us to measure coverage without duplicating tests

<bhill2> odinho: have that set up on the next cases I will check in to the repository

bhill2: any other actions to talk about for this section of the agenda?
... to take an action for himself to see what the granularity of "at risk" is

<bhill2> bhill2: what is the granularity of "at risk"?

odinho_: as far as I've seen that much is up to the chair to decide

gopal: pre-flight section 3.1 (2.1?), referenced in section 6 and 7

<gopal> section 6.2, item 7

gopal: section 6.2 item 7

bhill2: that's referring to a resource that advertises as requiring credentials
... it can't then turn around and grant to all callers
... what's the UA behavior -- not specified

dveditz: do we need to fix that in the spec?

bhill2: I'm going to take an action to figure that out

<bhill2> action bhill2 to talk to annevk and clarify UA behavior on section 6.2 if resource asks for credentials and gives * to preflight

<trackbot> Created ACTION-88 - Talk to annevk and clarify UA behavior on section 6.2 if resource asks for credentials and gives * to preflight [on Brad Hill - due 2012-11-08].

gopal: section 6.2 item 10 need clarification

… similar issue-- what's the expected behavior

odinho_: section 6 is for the resource, section 7 is for the UA and it probably says there

bhill2: does it say?

odinho_: yeah, we filed it as a bug when we implemented it if it wasn't there

bhill2: are we implementing test cases for the resource side of this spec? or only for user agents

odinho_: that can be outreach -- "we have a testsuite you can run against your server implementation"

bhill2: we don't necessarily need to cover the resource-specified behavior, it's outside our scope

<bhill2> http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

bhill2: scheduled for a break now… if you haven't looked at the UI safety directives now would be a good time to do so
... going to have a guest expert
... on accessibility, we don't want to deny users with accessibility requirements access to web content

CSP and inline styles

odinho_: when were we going to discuss the <style> issues with Jonas Sicking present?

<sicking> i'll be right over

tanvi: jonas isn't going to be here tomorrow, will try to find him on the break

<npdoty> the first [CSP] reference in the UI Safety Directives is incorrect, accidentally pointing to rfc2119

<bhill2> we are sticking around to discuss CSP and CSS issues while Jonas Sicking is here

<bhill2> mailing list archives are at: http://lists.w3.org/Archives/Public/public-webappsec/

<bhill2> part of the relevant thread is at: http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0065.html

<tanvi> csp and inline styles - http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0049.html

<tanvi> http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0060.html

<bhill2> jonas: right now, spec draws arbitrary line that blocks css from DOM attributes and DOM elements

<bhill2> ... sorry, CSS from text or attribute nodes is considered inline

<bhill2> ... but CSSOM methods like element.style.foo or element.style.csstext isn't blocked

<bhill2> ... even though they are feature equivalent

<bhill2> ... so line currently in the spec is obviously not correct

<bhill2> ... Adam might have some disagreement, but I think he generally agrees that we need to do something

<bhill2> ... my argument is that the threat doesn't come out of elements and attributes

<bhill2> ... but whether we are starting with a piece of text and turning it into something dangerous

<bhill2> ... concern is whether trusted code will take strings from untrusted locations and parse it into something dangerous

<bhill2> dveditz: long history of people doing dangerous evals, but style stuff more likely to be hard coded

<tanvi> ... into script or data or somewhere.

<bhill2> jonas: might be more likely that people will do bad things with eval, but doesn't mean they aren't also making css mistakes

<bhill2> jonas: if we think people aren't following dangerous practices, then we shouldn't block

<bhill2> dveditz: would be OK with that; argument for blocking them is that they may evolve to be more selector-like in the future

<bhill2> jonas: Adam has mentioned examples where css rules can mine data out of the DOM

<bhill2> dveditz: CSRF token is a better example

<bhill2> jonas: yes, but attack example requriese multiple loads, CSRF token may not be stable

<odinho_> scribe: bhill2

bhill2: not necessarily, may be stable across entire sesission

<odinho_> ScribeNick: bhill2

jonas: concern is that you can grab entire values out of page, but can't find a way today to send that out with current model
... but CSS is very close to being able to do that

<tanvi> … in a version or two. they just added calc.

jonas: calc, addr, eventually will likely have a way to concatenate strings
... then you won't need a rule, can just set, e.g. element.style.background = untrusted data
... could let you send something to a server

npdoty: not a problem unique to CSP, shouldn't we address that in CSS?

jonas: what CSP is trying to protect is when you have untrusted data that gets transformed by trusted content

npdoty: if that were an attack you could do in CSS in general, seems like that would be dangerous

jonas: only dangerous if linking to untrusted CSS

npdoty: or if you can include user-generated content, would be like reflected XSS
... CSP should have a narrower scope?

jonas: but we clearly know of cases where CSS can be dangerous
... blocking of style attributes is due to concerns that CSS will in future grow capabilties that make this dangerous

dveditz: also concerns with phishing by adding a floating div to cover up parts of content

jonas: key question is what kind of attacks we are trying to prevent
... only answer was from Adam on the CSRF token example

dveditz: yes, not clear to me

jonas: defamation not clearly a goal

dveditz: defamation has been mentioned in some places

<tanvi> is the goal of csp 1.0 to prevent csrf tokens from being revelaed. data exfiltration? just xss?

bhill2: just HTML can do that

dveditz: depends where in the page you can inject, may need to use CSS to move attack to right place

jonas: example where untrusted content injected into markup of the page that caused a start style attribute to happen, all of content got appended, turned into a giant url
... caused a request to go to a different server with all the legit data following that injection

dveditz: this is already solved by browsers

jonas: not so, request isn't invalid CSS being returned, it is the outbound URL being used to fetch the CSS

<tanvi> jonas: adam's point was that the css we get back is verified an dmake sure its valid. but at that point it is already too late. sending a request to the server that contains private data.

dveditz: example from crhis evans... yahoo subject stealing

jonas: attack was a valid piece of CSS with a valid external URL reference containing part of the original text of the page

http://scarybeastsecurity.blogspot.com.es/2009/12/generic-cross-browser-cross-domain.html

<tanvi> wrapping piece of original context with css that causes an off domain request. this would be stopped by image source. background image request. but woudln't be stopped by style source

jonas: this attack would be stopped by img-src, but not by style-src
... this is particularly bad, but also easy to stop attack
... fact he got it inserted into the markup stream can't work even with setAttribute
... because it isn't a markup stream anymore, so much harder to combine real data with attacker data
... seems totally possible to have javascript that contains data from different sources and then sticks that into CSS

<tanvi> dveditz - attack involved loading the email as a style sheet.

<tanvi> fix by checking the mime type. since its wrong, dont even load the style sheet

<tanvi> jonas - what i'm concerned about seems like a different attack, but still concern there

jonas: agree with adam's point, need to draw the line somewhere
... made a proposal on where to draw line

dveditz: didn't understand proposal - understood part about adding css-text
... anything else?

jonas: that is half of it, treating css-text as equivalent to setAttribute is half of it

dveditz: yes, that's innerHTML for CSS

<tanvi> treating as css-text equivalent to set attribute is half of it.

jonas: might be different in firefox, but injecting style rule is equivalently dangerous
... more formal way to describe proposal
... anything that can cause an arbitrary string to be parsed into a style should be blocked, just as we do with script

<tanvi> dveditz - woudln't block style.bg becaus e not an arbritrary property.

<tanvi> jonas - yeah

jonas: in theory can have defamation attacks, but at some point need to say it's your own fault
... other half of proposal is that I'm in general concerned with trying to block outgoing request using -src rules
... part of reason is to not send requests with sensitive information

dveditz: if that was only reason we'd have to do it globally
... any type of leak is equivalent
... is more like rules for mixed-script inclusion
... scripts are more dangerous than images
... so distinction in types of sources has to do with relative risk when including, not risk of exfiltration by retrieval

jonas: have enumerated a set of things to set policies for

dveditz: no font-src anymore
... may still be in Mozilla, not in spec

jonas: there are other things that can cause loads, set of things that can cause loads is constantly growing
... either keep adding more things to CSP spec and to policy
... or we create a better fallback mechanism than default-src
... have we considered that gecko supports loading SVG filters from CSS
... why stylesheet -> stylesheet loading is blocked by style-src, but SVG filter is only blocked by default-src
... unless explicit policy like font-src, anything loaded from a stylesheet should be required to be under style-src
... there will be more things added in the future like SVG filters, to falling back to style-src before default-src makes sense

dveditz: implementation-wise, might be difficult in gecko
... (earlier) font-src still actually in spec

jonas: in gecko, just treat SVG loads just like stylesheet loads as far as CSP goes

devditz: but other SVG loads that don't happen in that context

jonas: even when SVG links to other SVG, SVG is style-ish...

dveditz: to now we treat it more like an image

jonas: even for a filter

bhill2: can't you have script in SVG

dvedits: only run it for whole document SVG, not as an image or inline

joanas: we can solve it in Gecko, see what other implementers can do in their products

jonas: but maybe we should treat SVG from SVG as img-src, not style-src

<tanvi> bhill2 - how do we have forward compatibality as keep adding new types of resources. maybe new tag type with remote resource added to html

<tanvi> bhill2 - thats an issue with csp

jonas: treat it under whatever resource type seems most appropriate
... and only update CSP if it doesn't fit anywhere else

dveditz: should be a cascade of fallbacks - font -> style -> default

jonas: may be same issue with shaders, but not proposing we add it right now

<tanvi> dveditz - are images a subset of style?

dveditz: are images a subset of style? predate style by years

<tanvi> bhill2 - is this a complication that is useful to people when writign policies? or is it a complication that makes sense to security people who have incredible knowledge of how the DOM and CSS interact?

<odinho_> s/scribe ekr/scribe: ekr/

<tanvi> jonas - it does make the spec harder. the other way has to make you understand more of the platforms

<tanvi> currently nothing needing more than 2 layers of cascade. currently just have default-sr

<tanvi> s/default-sr/default-sr

<tanvi> s/default-sr/default-src

<tanvi> if currently loading svg one way, and in the future decided its controlled by some other directive, then we might break things.

<tanvi> dveditz - tricky if we change way things are currently covered and how they are covered in the future.

<tanvi> jonas - acceptable if we have to keep updating the spec for more fine grained control. its not a really acceptable if autthros will have to update all their policies everytime a new capability has been added

<tanvi> … makes it too hard to for them to write policy

<odinho_> i/for folks hoping to dial in, my apologies/scribe: ekr/

<tanvi> bhill2 - chosen so far that we have a best effort blacklist and we will always allow forward compatability. other idea of its a whitelist. that may not be wrong, but not the philosophy we've had so far. shoudlnt' be changing it at this point when about to go to cr

<tanvi> bhill2 - we dont have svg-src, we are still treating it as img-sr.c. if we didn't have media-src, do we it include it in default-src or img-src?

jonas: one concrete place to change this is to make font-src be a multi-fallback type through style-src, then to default-src
... that would be concrete change to make, then up to implementers to choose for things like SVG filters

<odinho_> :w

jonas: css shaders, etc.

<odinho_> s/:w//

<tanvi> jonas to make proposal to text. and bring it up on the next call when adam and mike west are also there.

<tanvi> s/proposal to text/proposal for text/

http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

is the current latest editor's draft, set to go to FPWD on Tuesday

<gioma1> hi

<gioma1> lots of noise here, but I can har you

can you hear us?

<ekr> gioma, can you mute?

<gioma1> I'm muted, are you talking? I don't hear you anymore

better, thanky ou

http://www.w3.org/Security/wiki/Clickjacking_Threats

<odinho_> scribe: ekr

<odinho_> [ introductions, and going through the wiki-page just pasted ]

dveditz: some of the "quick UI change" attacks may not work with accessibility modes

leoniewilson: the screenreader makes a copy of the key and then you interact with that.
... my assumption is that the screenreader would make the overlay manifest

peleus: how do screenreaders deal with floating ads?

leoniewilson: screenreaders generally don't care about anything that happens dynamically. they are almost exclusively concerned with the html

peleus: would it read the ad back to you

leoniewilson: would read the advert back to you because it doesn't care much about where it is occluded

dveditz: this is the kind of technique used to obscure stuf

leoniewilson: do you have any test cases?

bhill2: not yet really

leoniewilson: a screen magnifier is probably about as susceptible, though they are often keyboard reliant

bhill2: concern is that people with screenreaders will probably be ok, but that people who use other assistive devices (magnifiers, high contrast) etc. might be susceptible

bhill: [describes the proposed mechanism]
... do we need to improve the second paragraph of section 9.
... objective is to not have these heuristics deny access to users of assistive technologies to
... don't want this to deny access when AT is cause of the trigger
... can we tell if an AT is in use?
... can the application get signals that an AT is in use from the OS?
... and compensate?

leoniewilson: might work well for builtins but maybe a problem for third-party ATs

<JeffH> "AT" ?

AT -> Assistive Technologies

bhill2: [describes multi-window clickjacking]

<gioma1> gioma1: @ bhill: I don't believe we use OS screenshots agains multi-window CJ - as far as I can tell we use delays on rapid-fire clicks on different sites

peleus: could you just have automatic disabling.

bhill2: first goal is to avoid denying access in the case of an attack.
... second goal is to have these heuristics work with ATs

<bhill2> public-webappsec@w3.org

bhill2: this is an enabling technology. there are some susceptible sites/technologies but generally people avoid using vulnerable modalities.
... timeline is over the next year or so.

bhill: let's walk through the spec

<odinho_> i/I'm muted, are you talking?/Topic: Detailed review of FPWD of UI Safety directives (+ a11y descussion)

dveditz: i don't understand issue 3

bhill2: you only set the unsafe attribute in report-only mode
... does this mean anything useful to an application author

dveditz: should UAs supply this without sites opting in?

bhill

;

bhill2: if you didn't set that policy you probably aren't listening for unsafe=true

dveditz: just block?

bhill2: you don't think we should have a report-only mode?

<bhill2> ISSUE if browsers apply this heuristic without an explicit opt-in policy, should we always block and not have the unsafe UIEvent property

dveditz: if this is opt-in for the site, then this sort of reporting mode makes sense. if it's something that the site applies automatically, then you should just block

s/site applies automatically/browser applies automatically/

<bhill2> ISSUE: if browsers apply this heuristic without an explicit opt-in policy, should we always block and not have the unsafe UIEvent property

<trackbot> Created ISSUE-20 - If browsers apply this heuristic without an explicit opt-in policy, should we always block and not have the unsafe UIEvent property ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/20/edit .

<bhill2> ISSUE: do assistive technologies send real events or synthetic events?

<trackbot> Created ISSUE-21 - Do assistive technologies send real events or synthetic events? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/21/edit .

dveditz: we should have asked Leonie if ATs generate real or synthetic events
... does this require per-browser adaptation for the ATs

bhill2: unclear if they already have this problem b/c of kbd nav
... two issues (a) if we do this automatically, should we just block (b) should we have an unsafe attribute mode.

<bhill2> ISSUE: are there cases of synthetic UIEvents where it would be useful to set the unsafe attribute even if the policy is block (so event is not delivered)

<bhill2> ISSUE: are there cases of synthetic UIEvents where it would be useful to set the unsafe attribute even if the policy is block so event is not delivered

<trackbot> Created ISSUE-23 - Are there cases of synthetic UIEvents where it would be useful to set the unsafe attribute even if the policy is block so event is not delivered ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/23/edit .

<scribe> ACTION: ()()()( [recorded in http://www.w3.org/2012/11/01-webappsec-minutes.html#action01]

<trackbot> Sorry, bad ACTION syntax

ISSUE: ();

<trackbot> Created ISSUE-24 - (); ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/24/edit .

bhill: frame options. I believe it belongs in this WG
... not in IETF

<JeffH> couldn't hear dveditz

dveditz: complaints about frame options being part of CSP is that it was a policy of how to treat that content that you are loading rather than one describing how to render other parts included in that resource
... but now we also have sandbox which is the same type of directive
... so frame options does not seem quite the oddball

jeffh: does tha tmean the concern is moderated

dveditz: we have now staked out that CSP is not just policy of rendering of document but can also affect rendering of document that tries to include it
... sandbox and frame options are aimed to other documents that try to include that content

<bhill2> ISSUE: do frame-options directives (or other UISafety directives) make sense in a meta tag context?

<trackbot> Created ISSUE-25 - Do frame-options directives (or other UISafety directives) make sense in a meta tag context? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/25/edit .

dveditz: but neither one makes sense in a meta tag

<bhill2> ISSUE: does the sandbox directive make sense in a meta tag context?

<trackbot> Created ISSUE-26 - Does the sandbox directive make sense in a meta tag context? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/26/edit .

jeffh: is it worthwhile to differentiate on that basis

bhill: I objected to from-origin (1) violates priority of constituencies b/c it favors resource owner over that of user (2) wrong location to make the security decision b/c the client will turn it off
... point of x-frame-options is that it is operating in user's interest
... what happened to from-origin

dveditz: I don't think anyone was interested.
... I feel a little like we should help people who have resources that they don't want leached

bhill: I'm sympathetic to that, but I think if you create a mechanism that is visibly making the user less happy, we create an incentive that the users have an interest in turning off.

dveditz: a little worried about users turning off frame-options

tanvi: we do frame-ancestors

dveditz: from-origin isn't really a security feature
... except perhaps for jsonp

bhill2: if we want to start using a totally different mechanism it will create unhappiness at websec
... if we want to do something totally different, IETF might spec frame options.
... this looks and behaves like frame options.
... but default behaves more like frame ancestors
... x-frame-options compatible version is top-only

<bhill2> ACTION: bhill2 rewrite abnf production of frame-options to have deny alternating with top-only and ancestor versions [recorded in http://www.w3.org/2012/11/01-webappsec-minutes.html#action02]

<trackbot> Created ACTION-89 - Rewrite abnf production of frame-options to have deny alternating with top-only and ancestor versions [on Brad Hill - due 2012-11-08].

dveditz: should frame options apply to pluginc ontent
... was IETF OK with us taking frame options

jeffh: I think we did close on this with IETF. We should talk to Tobias in Atlanta

dveditz: why not allow multiple hosts?

bhill2: IETF felt very strongly about it.

<bhill2> http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

jeffh: original blog post proposed that server dynamically generate the header

<bhill2> think this is the blog post JeffH is referring to

<JeffH> what is bhill reading from?"

<JeffH> o

<JeffH> oh, ok

<JeffH> there's more than one x-frame-opt blog post, pls put uri in here

<bhill2> ACTION: bhill2 to sync up with David Ross and Eric Lawrence on XFO justification for ALLOW-FROM single origin restriction [recorded in http://www.w3.org/2012/11/01-webappsec-minutes.html#action03]

<trackbot> Created ACTION-90 - Sync up with David Ross and Eric Lawrence on XFO justification for ALLOW-FROM single origin restriction [on Brad Hill - due 2012-11-08].

<bhill2> dveditz: is there a reason to do this as a seperate spec vs. as part of CSP 1.1?

<bhill2> bhill2: two reasons - one, mechanism is independent of CSP 1.1 details, could be as an add-on to 1.0 without doing 1.1 stuff

<bhill2> ... second reason has to do with clarity of obsolesence mechanisms for X-Frame-Options

<bhill2> ... UAs should ignore XFO if it sees a CSP header with any of the directives of the UISafety spec

jeffh: who is proposing we do XFO as a separate spec?

bhill2: why don't we do the entire UI safety spec as extra directives in CSP 1.

(that was Dan's proposal)

bhill's response is (1) and (2) above.

ekr: is this baked enough to go into CSP 1.1

bhill: also, it has a confusing compliance story since you need to do the whole spec whereas CSP is generally a la carte
... this isn't CSP, it

's a different spec which uses CSP as a delivery mechanism

scribe: security considerations are really different

dveditz: does frame-options apply to redirected resources?

bhill2: not specified

dveditz: content loading stuff on CSP checks on redirects as well

bhill2: there was a bunch of refactoring of the input protection directives.
... I think Giorgio thought it was clearer to have separate directives in terms of readability
... last edit we had one input direction directive and then a lot of hints

<gioma1> also, CSS selectors parsing and multiple hints in one directive would clash

<bhill2> ISSUE: implementation concern on how to enforce display-time : should we provide more advice on how to do this efficiently?

<trackbot> Created ISSUE-27 - Implementation concern on how to enforce display-time : should we provide more advice on how to do this efficiently? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/27/edit .

dveditz: what does being tolerant mean?

<dveditz> is it a percentage of pixels difference?

<gioma1> tolerant means percent of checked pixels which may not match

peleus: from a baseline perspective there are going to be some pixel differences (E.g., color correction)

<gioma1> personally, I'm against to keep it in an opt-in context, but it may be useful to lower the false positive rate in a default mode

<bhill2> puhley: might need sub-pixel tolerances to prevent e.g. color-correction from causing total failure

<bhill2> ... if using OS-level screenshots

<dveditz> gioma1: we discussed that a little, that to be generally useful browsers should just implement it

<gioma1> does using OS-level screenshots provide any advantage over browser-based ones?

bhill: do you have an example we could do a test case for.

<bhill2> giorgio, I know that David's InContext work used OS-level screenshots to prevent the double-click attacks where click one closes an overlaid window and click two is delivered to the window beneath

<bhill2> sounds like you think that protection can be afforded using display-time without relying on OS-level facilities?

<gioma1> bhill: in that case you just need ensure that the surface you're clicking has not been repainted too recently

<gioma1> bhill2, yes indeed

ekr: what value would you use?

<gioma1> (after a click on a different domain)

<bhill2> ISSUE: what specific attacks are prevented by OS screenshots, should this be recommended against generally?

<trackbot> Created ISSUE-28 - What specific attacks are prevented by OS screenshots, should this be recommended against generally? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/28/edit .

<gioma1> I currently use 600ms

<gioma1> ekr, I defaulted to 800ms in the spec because it's opt-in

peleus: people probably start with 0, break everything, and then will whipsaw back to 99. maybe we could have a max value of 20 or 25 or something.

<bhill2> so many things might be simpler if we could recommend implementing entirely in the browser, and never going to the OS

<bhill2> no issues with color correction, assistive technologies at OS level, etc.

odin: I just tested red shift on Linux and it only changes output gamma

bhill2: input-protection-clip
... centered on the mouse event. keyboard event is centered on text entry

<bhill2> giorgio, any reason to use before/after/above/below vs. more CSS-standard top/bottom/left/right?

<bhill2> dveditz: before/after creates confusing with text directionality

<gioma1> because top, bottom etc are traditionally relative to the viewport

<gioma1> (or the parent element)

<bhill2> puhley: could use positiveX, negativeX, etc..

<bhill2> dvedits: could we just specify width and height, instead of an offset rectangle?

<bhill2> s/dvedits/dveditz/

<bhill2> dveditz: why are there four values?

<gioma1> dveditz: because we may want not to have it centered always

dveditz: so you are sayingi f the important thing on the page is lopsided compared to where you click...

<gioma1> for instance, if I click on a form button, I'm probably biased toward left and top (in a ltr page, that is)

<bhill2> so if I have a pay button with a dollar value printed to the right

<bhill2> want to have that protected from being obscured, but may not care about context to the left

peleus: concerned about doing exact math on text that wraps. need to have a recommendation for this.

dveditz: do you always have to specify all 4 sizes

<gioma1> peleus, if that's a concern, you may use input-selector to match the container

bhill2: they are able to be specified independently. defaults are 250...

peleus: if the page is longer than the visible area of the screen, does the screenshot account for that

<bhill2> gioma, how does screenshot account for clipping from a scrollbar?

<bhill2> when "the whole document's body" is used for comparison according to the algorithm?

<gioma1> bhill2, it doesn't.

<gioma1> bhill2: "whole body" is the like button case

<gioma1> bhill2, Facebook Like, that is.

<bhill2> aha, ok

<gioma1> bhill2, so if you've got a complex page, you'd better use input-protection-selectors or input-protection-clip

<bhill2> should that be default if clip isn't specified then, or should the 250,250,50,50 values be a more sane default?

<gioma1> (the latter even with no values, using the default form-biased rectangle)

<gioma1> bhill2, I think there's where I and David disagreed, and we went with his idea of the whole body as the default IRC

<dveditz> gioma1: I'm slightly confused that input-protection-clip defaults to 250,250,50,50 but input-protection-selectors defaults to 0,0,0,0

<bhill2> sounds like we should raise an issue on this for broader discussion when David can also join

<gioma1> dveditz, ooops, selectors should be a CSS string? did I miswrite a default value somewhere?

<bhill2> ISSUE: what are sane defaults for clipping with clipping or selectors?

<trackbot> Created ISSUE-29 - What are sane defaults for clipping with clipping or selectors? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/29/edit .

<dveditz> no, I'm shorthanding

<dveditz> "may be omitted, taking 0 (zero) as their default values."

<dveditz> vs "The default value for this directive is before=250 above=250 after=50 below=50. "

<gioma1> dveditz: ah ok, because in my view you usually want to select the container, rather than the protected element, when using selectors

<gioma1> dveditz, in other words, if you can't control the DOM and shoot in the dark, you use clip, otherwise you can use CSS selectors and have the padding from the DOM itself

<jeffh> meeting over?

<dveditz> gioma1: oh! I missed that the calculations were different

<dveditz> also

<dveditz> just assumed they were both the event point

<gioma1> dveditz, no they aren't, that's the point :)

<jeffh> sorry I missed the question about XFO directed to me by ekr in the chat -- followup via email?

<dveditz> got it. thought the point was to use both and have a default area around events, and then specify a (presumably bigger) area around particularly important elements

<gioma1> dveditz, in facts, you can use both.

<gioma1> dveditz, the text says selectors override clip when the clicked element or an ancestor matches the CSS

<gioma1> dveditz, otherwise clip applies if specified (so you can both shoot in the dark and make some DOM-based fine tuning)

<dveditz> gioma1: so the default input-protection-clip size is 500px across? seems pretty big -- especially for a mobile device!

<dveditz> what happens if the specified clip area is bigger than the display area, or runs off the edge of a page?

<gioma1> dveditz: it's 300x300 as far as I can tell

<gioma1> dveditz: what ClearClick actually does is sliding the minsize rectangle inside the viewport if possible, otherwise trigger

<gioma1> dveditz: in an opt-in context I'd be tempted to be stricter, since the author is specifying his preferred rectangle

<bhill2> gioma1, I think we are wrapping up here

<bhill2> thanks for joining on a holiday, and best of luck tomorrow

<gioma1> bhill2: sorry, I'm leaving. Thank you, I hope it's not too painful :) Bye

- DRAFT -

WebAppSec Face to Face, Day 1, TPAC, 1-Nov-2012

01 Nov 2012

Attendees

Contents

CORS and WHATWG fork of "Fetch", guest speaker annevk

CORS test status

CSP and inline styles

Summary of Action Items

Scribe.perl diagnostic output