WebAppSec TPAC 2016 Day 2 -- 23 Sep 2016

referrers for CSS contexts (continued from yesterday)

<bhill2> jochen: which referrer and policy should we take for CSS and CSS subresources given different behavior in FF and Chrome

<bhill2> jochen: either you propagate the policy or you define that the policy comes from wherever the referrer comes from

<bhill2> bz: or pick the most restrictive

<bhill2> bz: who cares about these referrers?

<bhill2> jochen: font providers

<bhill2> dveditz: can't you just then use a stylesheet from whatever allowed site you want?

<bhill2> bz: but font load use CORS

<bhill2> jochen: I think they want both Origin and Referrer

<bhill2> bz: so they already have the origin of the actual page

<bhill2> ... other option is use referrer policy from stylesheet, if they want something else the CSS WG can spec something

<bhill2> jochen: change in impl for firefox

<bhill2> jochen: so would say that referrer policy comes from wherever the referrer comes from

<bhill2> bz: seems reasonable

<bhill2> bz, I know you have concerns about window.ancestorOrigins

<bhill2> bz: yes, leaks the entire chain into the page

<bhill2> ... in particular not happy with, ad knows all the domains you visited

<bhill2> ... page could communicate that, but now they can get them

<bhill2> dveditz: in the ad case there are many layers

<bhill2> ads always need to know, part of the contract to be paid

<bhill2> bz: is being able to query "am I embedded in X"?

<bhill2> I don't think that's enough, leaks information, and hard to make decision in realtime

<bhill2> dveditz: could this work if you could query about the top?

<bhill2> jochen: e.g. get a postmessage with the origin, be able to verify if it is top

<bhill2> what about re-stuffing in a legitimately purchased ad?

<bhill2> dveditz: but intersection observer would tell those ads they weren't actually visible

<bhill2> dveditz: could a click event carry the ancestorOrigin chain with it?

Threat Models

<wseltzer> [minuting in agenda doc]

<bhill2> mkwst, what do you want?

<bhill2> mkwst: want to know what other browser vendors want to build, will build, care about?

<bhill2> teddink: more a question for Crispin, will ping him

<bhill2> mkwst: seems there are several teams at Microsoft with different areas of responsibility, want to know who actually has the ability to implement

<bhill2> artur: want to be able to prevent common classes of vulns that server-side frameworks have been unable to completely prevent

<bhill2> mkwst: maybe we have all these things already and need to get them implemented

<bhill2> annevk: maybe we want to tell websites that a browser is sandboxed to a certain degree so it would be safe for more dangerous things like bluetooth, e.g.

<bhill2> annevk: folks at mozilla are pushing back on many of these things and is getting stalled

<bhill2> artur: before we get better at fixing the baseline vulns like XSS, it is very scary to grant these more powerful permissions

<bhill2> ... because XSS can do much more damage (paraphrased by scribe)

<bhill2> mkwst: may be useful for this group to give more input to the TAG on new features and classes of features that may need certain restrictions

<bhill2> ... on Chrome team there are many discussions on whether a feature is "powerful" and should be restricted to https

<bhill2> ... would be nice if we threw away the word powerful, just said feature and were done

<bhill2> ... but we could be influential in doing this and helping groups like TAG do this

<bhill2> hadleybeeman: TAG doesn't want to become bottleneck, so help from domain experts is good

<bhill2> teddink: but this group doesn't need to be the bottleneck either

<bhill2> hadleybeeman: we do questionnaires and things like that to push as much work out to groups themselves, to be more scalable and only bring the interesting questions back to groups

<bhill2> annevk: mozilla proposed dropping "powerful" at some point and you said no

<bhill2> mkwst: at the time I thought I was right and in hindsight it has caused problems

<bhill2> ... is right looking back at things we need to take out of http access

<bhill2> ... geolocation...

<bhill2> ... with benefit of hindsight, in my opinion, when looking forward we are applying same standard, incorrect, we can do better

<bhill2> ... if folks in this group agree, maybe writing that up would be helpful

<bhill2> ... deprecation and advice for new features are different use cases that have been conflated

<bhill2> annevk: richard barnes would probably be on the same page

<bhill2> ... you can encourage more specs to start using secure context notation

<bhill2> ... don't know if anyone is opposed

<bhill2> mkwst: people I know opposed are not in this room

<bhill2> dveditz: I have a concern about blocking non-powerful features to the extent it makes it look punitive and arbitrary, which makes things that are powerful also look like arbitrary decisions

<bhill2> mkwst: carrots and sticks

<bhill2> jeffh: can you clarify

<bhill2> mkwst: painful to take away things that already work, like geolocation

<bhill2> ... breaks things on websites that worked before

<bhill2> ... but new features like intersection observer or whatever, defacto there is no breakage by limiting to https

<bhill2> dbaron: intersection observer seems like an interesting case there because it was designed to solve a performance problem with existing content

<bhill2> mkwst: IMO default stance should be to lock it down, and if there are great reasons not to, let's discuss, but let's flip the default stance

<bhill2> ... to restrict to https

<bhill2> annevk: long term goal is entire web to be only a secure context

<bhill2> mkwst: in some point we will stop shipping features over http

<bhill2> ... everything between now and then is delaying that day

<bhill2> mkwst: we passed a milestone recently that users are hitting https more than http, so this kind of stance becomes less restrictive

<bhill2> annevk: and we can start flagging sites that aren't secure

<bhill2> dveditz: 48% of page loads on mozilla are https

<bhill2> bz: but that could be that 48% of people's time is spent on facebook

<bhill2> bz: most interested in fraction of unique origins

<bhill2> would e.g. IPFS be considered "secure"?

<bhill2> mkwst: as the web evolves and its character changes, update what counts as a secure context

<annevk> bhill2: https://www.mnot.net/blog/2015/08/18/distributed_http is a pretty good analysis of a distributed web

<bhill2> does that harm innovation by introducing lag in feature availability for new things?

<bhill2> mkwst: give developers a way to opt out?

<JeffH> related IETF background: https://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/

<JeffH> Pervasive Monitoring Is an Attack -- https://tools.ietf.org/html/rfc7258

<bhill2> jeffh: only controversy I recall is about optimistic encryption without authentication, whether that gives false sense of security

<jkt> Does no-referrer on a <style /> remove all referrer's for all subresource requests within the stylesheet?

Proposed Experiments

<bhill2> https://mikewest.github.io/artur-yes/

<bhill2> mkwst: simplified syntax defined currently in terms of string-concat to produce a CSP policy

<bhill2> ... just a 15 minute strawman

<bhill2> francois: hashes?

<jkt> *I meant <script> and js... ignore me haha.

<bhill2> mkwst: either a nonce keyword, url keyword and hash keyword

<bhill2> ... devdatta wanted to be able to specify a single bootloader script, but we can't currently express that in CSP

jkt: a referrer policy on an html tag controls the load of that resource, not the execution of that resource

<bhill2> mkwst: except to use strict-dynamic you have to do everything in CSP to support browsers that don't do strict-dynamic

<bhill2> ... so nonce, unsafe-inline, etc...

<bhill2> ... this is significant simplification in deployment: one step mechanism, supported or not

<bhill2> ... don't underestimate simplicity

<jkt> dveditz: yeah I realised for both CSS and JS the only way to impact the referrer of sub requests is the header

jkt: there was a question about inheritance of referrer policy into stylesheets (since the referrer of things inside is the sheet rather than the page), but for scripts it would be the page's referrer policy

<bhill2> artur: but still have issue of browsers that don't support this but all the other things

<jkt> dveditz: I was following that as I'm writing up CSS -> fetch integration :)

<bhill2> francois: from POV of evangelizing best practices to developers this is much simpler

<bhill2> mkwst: if the mechanism of strict-dynamic is good and valuable to developers, let's make it super easy

jkt: we don't currently pay attention to a referrer policy http header on a stylesheet, but we could specify that (as an example)

<jkt> dveditz: I think we should, I wrote that down as how it works anyway haha

mkwst: john w thought there were 6 categories of secure contexts
... secure transports, strict secure transport, validated secure transport (EV cert), managed resources (some CSP), Integrity checked (SRI), single trust (single origin)
... not clear what kinds of things they are thinking about, but certain privileges would require particular levels of secure contexts
... but in general Apple wanted us to consider more than mere "secure transport" (https)
... if we know that a website has restricted itself in certain ways maybe that's enough for us to trust it more
... in general seems reasonable, although I'm not convinced of the value of particular levels here

bhill2: from a different place a similar idea is "transparent applications". Yan Zhu was interested in this when working on E2E mail for Yahoo
... facebook has a similar problem with E2E encryption in messenger. we'd like to offer it on the web but it's hard to make the guarantees required to do so safely
... 2 years ago we didn't have ways to do this, but maybe we're getting closer now with some of the proposals in this group
... strawman "verified app": create a suborigin prefix (a special one) + SRI + CSP
... prefix: $VERIFIED$key_hash$suborigin_name

mkwst: have you seen the "packaged web" proposal from tag? google folks are looking at extending this to offline apps
... what you're proposing is different from theirs, but it's the same problem space so maybe you can get together on that

<hadleybeeman> We were talking about reopening the packaging work in the TAG anyway — could be good to include this discussion

bhill2: CSP policy for script/style the forbids unsafe-inline and -eval, and object-src none
... SRI tagging mandatory for script/style. forbid non-parser-inserted scripts. persistent client-side storage with a signing key required to update it
... a way for the code to check its integrity

artur: are you expecting that the application might try to load things outside its sandbox, or are you trusting the signed code?

bhill2: I want to make sure all users see the same application

artur: but the application could do something different for different users based on what it loads (treating an image as script?)

bhill2: yes, you'd have to audit the code. a 3rd party could attest "there isn't a secret eval-engine hidden in this known code"
... or "it's too complicated to evaluate this version of the application -- don't trust this black box"
... then people could share hashes of "known trusted" versions of the app

teddink: we don't do all of this, but similar to how we do trusted applications on windows HTML apps.
... could be all packaged and hashed, or just a manifest with a URL that's run in a different security context
... than just a web browser -- gets access to some windows RT APIs (similar to "powerful features" concept)

bhill2: I'm most interested in having a well-defined set of active code sources that could be audited. not that the platform makes the trust decision but that it allows people to make that decision
... "this is simple and consistent" vs "this is obfuscated and untrustworthy"
... this requires you to be more transparent with what your application contains, but not as restrictive as requiring a single origin (and the contrivances of making CDNs look like it's the same origin in practice)
... when code changes you'd have to re-grant the permission, and you could check the hash through some gossip protocol
... seems possible to construct from the pieces we've now defined, couldn't before.

Isolate-me

origin-policy

mkwst: a mechanism to define origin-wide policies. CSP is a resource-specific header. Some features need to be origin-wide, such as HSTS and HPKP even though the current mechanism is tied to a resource load.
... a well-known manifest location. If the response specifies an origin policy we need to block until we load the manifest, though in practice it will be cached or Http2-pushed ahead.

dveditz: does a loaded origin-policy apply to all resources that don't specify the header?

mkwst: yes -- once the origin-wide policy is set it applies to the origin (or subset)

dveditz: does it have an expiration time?

mkwst: just the normal http caching mechanism
... brad suggested a non-blocking mechanism. I intend to put this in the WICG and experiment with it in chrome

bhill2: facebook likes this idea. one concern I have is if you have a default restrictive policy, but one resource needs a weaker policy what do you do? an eviction algorithm? overrides?

artur: we talked about this as well. some resources would have trouble working with the default. I like the grouping ability in origin-policy so we can exempt certain ones

mkwst: the policy can define whether a specific header overrides a resource-specific one, or whehter it's only used if the resource doesn't have one of its own
... mnot proposed header blocks for certain "groups". maybe implicit grouping by paths (I'm reluctant to start with that), or explicit groups
... we can figure it out

bhill2: a little concerned with the semantics of do you replace or override a header

mkwst: this is explicit in the policy -- you can pick which works for your app
... baseline always applies, and resource can tighten
... a fallback policy only applies if a resource doesn't specify one
... maybe we need different names "overridable" or whatever
... mark's proposal is all about headers and inserting them along the way ("magic middleware")
... but I want some things that aren't headers, because not everything is a header.
... Mark's proposal linked at the bottom. "Site-Wide HTTP Headers"

<bhill2> this proposal:

<bhill2> https://mikewest.github.io/origin-policy/

<bhill2> mnot's alternate:

<bhill2> https://mnot.github.io/I-D/site-wide-headers/

bhill2: if we had something that shouldn't be a header because a single resource shouldn't have to specify it ????

mkwst: this is at a well-known location and the header opts-in to using it, but not "which" one or where it is
... I've only defined one thing that's origin-wide that isn't a header (cors preflight policy) but we can come up with more

rechartering and relationship to WICG specs

JeffH: is there a mailing list for WICG?

<wseltzer> https://discourse.wicg.io/

chris: no, we use discourse as our firehose

bhill2: does WICG have specs that are intended other than ones for web platform?

chris: we had one that went to Payments, but most are aimed at Web Platform WG
... but it's been brought up that when we start looking at a new idea we need to advertise to the appropriate group that we're working on something that might be headed their way

mkwst: how do you feel about joint deliverables?

chris: one group ends up taking up the bulk of the work. that can be OK but a messy way to get input from members of other groups who don't want to join your group

bhill2: we have an odd situation here in that we have an existing spec for anti-clickjacking, with IPR from invited experts and so on. Some of that might live on in the scope of the "intersection observer 2". if that happens solely in WICG then the IPR is cloudy
... could that happen as a joint work to preserve those commitments?

ojan: the current intersection observer isn't a security mechanism in any way

bhill2: I'm not saying it has to move here, I'm just saying that when it needs to graduate to a WG it could go here to preserve IPR

chris: if it's not the same spec I'm not sure those commitments hold anyway
... if you take ideas from one spec and put them into another spec I don't think the IPR carries over

wseltzer: if you have a spec and replace all the text the IPR is preserved even though it's all new
... but if you start a new document we have to define the IPR commitments anew

bhill2: you think this is going to graduate to CSS?

ojan: prior to this week it was maybe going to go to Web Perf, could go here?

bhill2: facebook is a member of web perf, we could get White Ops to join, that should be fine

mkwst: we need to recharter some time, and how do we recharter with some things from WICG likely to graduate to our group at some point in the future

<wseltzer> current charter

chris: when you recharter you have to say the things you are going to accept. Doesn't need to be specific by name, but it has to fit in the scope

mkwst: we're not interested in the perf aspects of intersection obs, but in the anti-clickjacking aspects

chris: your scope has to cover the whole spec, or it has to be a joint deliverable with some group whose scope covers the part yours doesn't

bhill2: how do people feel about accepting these WICG specs into WASWG?

mkwst: our existing scope seems to cover things we want to do with few changes, maybe less specific about deliverables

bhill2: how does it work that WICG takes on new specs that are expected to eventually graduate to other groups, but the other groups have strict scopes they may not fit in

wseltzer: if we were to accept specs from another working group we would need to reference it in our charter, but we can recharter at any time. things from WICG that aren't a Working Draft in a specific WG we can take if they fit our scope

bhill2: Origin Policy, CORS 1918, and HSTS Priming seem to fit our existing scope just fine
... W3C would like to republish the Fetch spec.

chris: parts of it are CORS-like, but you'd have to expand your scope to include it all

mkwst: I think it would be more successful here than in web platform

wseltzer: there's the technical aspect of "we need to get this right" but also IPR "are the right people on this"

mkwst: ideally it would go in web platform as a foundational technology, but it would be more successful here

<wseltzer> wseltzer: it's an important piece of the web platform security; we need to integrate with it to get our security specs right, and to give the right guidance to implementors and developers

bhill2: we would definitely need to expand our scope to accept it. Facebook might have a concern if aspects of push are in it
... the point of bringing it into W3C is the IPR commitments, but then we have to worry about our lawyers bandwidth bringing it here

wseltzer: there's a 90 day period after the first working draft, and then the next call for exclusions is at CR

JeffH: the question being begged here is that the W3 IPR commitments don't fit a "living standard"

mkwst: we talking about yearly snapshots, not a "living" version

bhill2: I get pushback that we have limited legal resources that I have to spend carefully

SRI 2

francois: I've spoken with the other editors. first priority is to upstream the bits of SRI that should go in HTML and fetch
... 2nd is to specify the links required by the "require-sri-for" directive such as the ability to specify hashes inside stylesheet
... and joel wants to explore an addressable hash
... and devd wants to explore using asymmetric keys, unclear developer interest

<wseltzer> [WebAppSec in #wpay for 30min]

<jyasskin> I've started a Hangouts on Air for the Permissions discussion at https://hangouts.google.com/hangouts/_/ytl/znkSLqTYWCxNufxijU7R7InTE9dVVJiavbVXk7ab0B4=. It'll record the session for posterity.

<jyasskin> The recording will be at http://youtu.be/HBHYUU_9ijY.

<annevk> FWIW, there's someone on the queue here

<slightlyoff> we haz no zakim = \

<annevk> slightlyoff: I'm sorry, I think I missed some of the argument around request()

<annevk> jyasskin: marcosc_: well, one-time permissions don't really work with the current model...

<annevk> oh well

<jyasskin> annevk: They totally do.

<annevk> jyasskin: hmm, no they don't, because then the call for the API would fail

<slightlyoff> +1 to what mounir said

<annevk> mounir: I don't know, I just know it's there

<annevk> mounir: also, I'm not really sure how we can solve this here without those other people in the room

<mounir> annevk: +1

<mkwst> marcosc_: You should send teddink an email, and ask him to hook you up with folks at Microsoft who might care.

- DRAFT -

WebAppSec TPAC 2016 Day 2

23 Sep 2016

Attendees

Contents