Web Application Security Working Group Teleconference -- 28 Oct 2015

<wseltzer> trackbot, start meeting

<trackbot> Date: 28 October 2015

<wseltzer> Meeting: Web Application Security Working Group F2F, Day 1 (TPAC)

<scribe> Meeting: WebAppSec F2F, TPAC 2015, 29-Oct-2015

<scribe> Agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit#

<dveditz> scribe: JeffH

minutes approval

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-19-webappsec-minutes.html

<bhill2> minutes unanimously approved

WebAppSec WG Update preso by bhill2

<jungkees> https://www.irccloud.com/pastebin/YTSsB2Vl/

<jungkees> Can we add it to the secure context agenda?

<wseltzer> Brad's WebAppSec TPAC2015 update slides

<wseltzer> ^Brad's slides

[ Slide: 3 - Broad Themes ]

[ Slide: 6 - Subresource Integrity (SRI) ]

[ Slide: 7 - Referrer Policy ]

[ Slide: 9 - Upgrade Insecure Requests ]

[ Slide: 10 - User Interface Security ]

[ Slide: 11 - Credential Management Level 1 ]

bhill2: questions?

?: asks about diff btwn "creds mgmt" spec and the work in "creds CG"

bhill2: the latter is about "creds" like driver licenses, not username/pswds which is what creds mgmt spec is about

mkwst: creds mgmt api is extensible and we are working to take into account the creds CG's use cases

<npdoty> Brad's WebAppSec TPAC2015 update slides (world-readable link, per bhill)

mkwst: have secveral specs trying to give websites better functionality to ease migtation to https, eg upgrade insecure requests

<Zakim> npdoty, you wanted to ask about clear-site-data or private browsing

npdoty: curious about clear-site-data

<bhill2> ED: Clear Site Data

mkwst: there is a spec, have someone impl'g this qtr, will have impl early nxt yr. spec has been stable.
... some discussion re private browsing mode -- eg webapp policy to only be loaded in incognito mode -- need to restart that discussion

francois: wrt private browsing mode aka icognito, went to women's shelter for use case, they didn't think would make sense to require all users of their webapp to use incognito mode

?: they are thinking that having some sort of way for user to "clear all website data" for given site/webapp is better way to go -- mkwst: please chat with Tara et al

<Zakim> deiu, you wanted to ask about error codes (API) when mixed content load errors are triggered

bhill2: webapp is authoritative for its data, but users' browsing history the user is authoratative for it, so would require some sort of user interaction

andrei: is there any kind of api or way to get to the error when a mixed content req fails -- i as dvlpr don't get the info easily, but especially annoying for users, and no

easy way for the webapp devlpr to display meaning ful into to user

mkwst: there's ways to do that now eg leveraging CSP, TimBL was asking last night about a diff status code that comes back on XHR -- but there's limits such as if it is a redirect can't give the webapp access to the target of the redirct -- doing some thing like a status code or firing a mixedcontent event, pls file bug on the spec and make suggestions

dveditz: folks often don't have onError on everything...

mkwst: there's a variety of ways to give developers the info they desire/need

rbarnes: leery of giving folks "timing" apis for priv concerns

mkwst: if u have specific concerns pls talk to web perf folks (they ahve timing apis...)

rbarnes: just want to make sure that if we add anything we do it carefully

<npdoty> I think francois's point was that a more valuable mechanism would be clearing recent history for all sites (so as to remove the search engine results page before you clicked on the particular site, for example) as opposed to private browsing mode for that whole origin, so it would be more like a prompt for browser ui for clearing local history

bhill2: look at what info you get from CSP "default-src: https" -- think about the developer senario cuz it is diff w/XHR.

dveditz: hmm might be other ways to do it...mkwest: pls file bug

keiji: saw something about fido mentioned -- new web authn wg proposed -- what rel will have with cred mgmt api ?

dveditz: cred mgmt api here is extensible and hopefully the web authn wg can use it as basis for its work

mkwest: we want to think about creds sourced by say oauth, and perhaps that gives the creds CG what they need because they are somewhat similar

bihill2: we can discuss this later today

Subresource Integrity

?: pretty much ready to go to CR, have some minor issues to address

need to do a bit more work on test harness

bhill2: we can go to CR with what we have

dveditz: issues are spread across 2 diff repos, we need to move issues?

?: pref would be to move issues

<dveditz> SRI: needs integration with whatwg/html issue-486

dveditz: issues of note

<dveditz> reconcile/cross reference CSP and SRI hash behaviors issue-363

<dveditz> Review the stability of all referenced documents issue-3

<dveditz> Convert to Bikeshed issue-12

?: #486 - planning to do that one, but is in a diff spec so not blocking us

francois: #363: needs more discussion -- bhill had good response to consider

bhill2: devdatta has been asking questions about this also -- do we need to add explainer text for the current specs SRI and CSP?
... goals and thread models explained well in each sep spec -- not sure is worth it

mkwst: would be useful to ahve a general explainer doc on how to use the suite of webappsec specs to construct a secure site -- -take this in consideration in CSP3 -- don't want to add to CSP2 which is almost done

ndoty: would be valuable to do overall explanation -- webplatform.org might be place to do some of this

<npdoty> https://www.webplatform.org/

<npdoty> npdoty: +1 to the goal, doesn't and shouldn't be in the specification which has a very different audience

bhill2: better dvlpr doc would be a good thing, but getting folks signed up to do this work difficult, but thinks we can close this #363 in terms of its relation to SRI and CSP2
... <does some changes to issues #363 to reflect this>

dveditz: the other issue is secretarial -- so will send the transition message for SRI next week

CSP 2 to REC status

bhill2: We have an implementation report for CSP level 2

<npdoty> Implementation Report for Content Security Policy Level 2

bhill2: have 3 or 4 hundred tests for CSP2 but not everything is covered yet, so could use help in writing test cases

see report linked above to see ones that need to be added

overall status on CSP2 tests in chrome and FF -- see rpt above -- both browsers have CSP2 aspects still to implement

bhill2: would prefer to go to Prop Rec having solid impls and test suite coverage

francois: we will try to do that with SRI also

bhil2: to go to rec need all normative refs at same matiurity level -- there's ways to finess this -- but really want to have assurance of solid normative text when going to PR thus need test suite and impls to be solid

[ BREAK TIME till 1030h local time ]

<dveditz> scribe: dveditz

Secure Contexts

bhill2: our calls have moved from "covering recent topics" to a rotation featuring a group of specs each meeting, rotating through the many specs we have over several weeks

mkwst: "Secure Contexts" is pretty close to done, a couple of topics worth discussing

<bhill2> Secure Contexts

mkwst: a "Secure Context" needs to be delivered securely, e.g. over TLS (with some exceptions such as local file:///, loopbacks etc are considered secure)
... diagrams showing how different contexts work with each other
... we saw some "abuse" where inner secure frames fed data back to insecure frames
... Example 2 (in spec): is a TLS popup from an insecure page a secure context?
... yes, seems only tangentially related. we see this in the case of navigations for example.
... would be strange to consider a secure page as not a secure context because it came from an insecure page.
... however, there's a chance for leakage
... also one could have a handle (window.open/ opener) and can postMessage() each other
... there can be complicated situations. Talked a little with Travis from microsoft. he's concerned with this use-case
... we might want to consider a popup as a tainted context

rbarnes: we might want to do what we do with workers, just break the connection. Don't let the insecure context have a handle to the secure one

mkwst: we have a referrer relation. the page can say "rel=noreferrer" and if we do that there's no leakage. We can consider it secure in that case
... I've opened an issue with annevk to create a rel=noopener because sometimes you _do_ want the referrer and really were just using it for the noopener side-effect

annevk: That's what makes it auxiliary, and if you break that then it's no longer an auxiliary context. No tainting
... are we limiting broadcast channel?

mkwst: there's still a variety of side-channels (message events, etc)
... trying to make it more difficult to do the kind of shim Netflix has done. I don't think they would use a popup in this way
... what Travis didn't like was that this would be difficult to implement in edge
... he would like it so that if two things are same origin they have to have the same security context
... we remove window.opener. can null out window returned from window.open(). can still get a handle by naming it and then window.open() to the same name. once you have a reference there's a variety of ways to communicate
... I don't think Chrome has iplemented broadcastMessage() like Firefox, but even without that there are storage change events and others

yoav: why would localStorage be hard? couldn't they pass the data by stuffing the answers in localStorage?

<npdoty> what is the threat that we're trying to prevent against? a network attacker modifies an HTTP page, and opens an HTTPS page, and the HTTPS page collaborates with the network attacker?

rbarnes: because they'd have to do so from a popup and we think they wouldn't want the annoyance of a popup

<bhill2> ack

<bhill2> ack document.domain?

jyasskin: do you want to bring up the document.domain question? Do you want to block access from a secure context?

mkwst: yeah, I'd be happy to do that. we already restrict a number of things from secure contexts in chrome

annevk: but secure contexts are not opt in, how would you do that without breaking old sites?

mkwst: I'd do it the other way, touching document.domain turns off the secure context, possibly breaking access to objects the context already has references to

jyasskin or if you do something that requires a secure context (e.g register a service worker) then it turns off document.domain

mkwst: question came up wrt service workers, should things that are not usable securely be invisible, or should they throw?

<Zakim> npdoty, you wanted to understand the threat of the network attacker

npdoty: I'm trying to understand the threat model here in the embedded iframe
... if something is delivered over http with a link to https, that's a secure context. It may not be the one intended by the original author, but it's still secure
... users can't see the origin of a frame, but they can in the case of a popup

bhill2: I see the threat model here as asking for permission, if the user sees one thing in the urlbar and the iframe is a different origin
... everywhere else the context is authoritative for its origin, it's allowed to leak data if it wants to

rbarnes: if we say feature X is only available to secure contexts then an attacker can frame a secure page and use postMessage to get access to that feature

npdoty: are you worried that the framed site is collaborating with the attacker? you can always collaborate

mkwst: it may not be intentional collaboration, it's just a feature that was found and used in that way

bhill2: we're still not enforcing confinement here. we're stopping an obvious and convenient bypass but there are still other ways available

mkwst: I agree, it's not complete isolation
... I don't think it's necessary. It would be wonderful to do that and I'd like to but not sure we can. this seems reasonable to not break things on the web too much while giving developers tools to do their jobs
... popups get in the user's face, less likely that it would be abused.
... what owuld you like to see in the doc (or anywhere) to make that a reasonable claim to make

<npdoty> I think the unintentional collaboration point is important; if we think it's likely to create a danger where a site will typically make it easy for network attackers to access, that makes sense

<npdoty> +1 "attractive nuisance"

bhill2: sounds like there's not a particular threat model, we're closing down an attractive nuisance

mkwst: we're closing down a practical way to abuse this we've seen in the wild

jyasskin: if someone can find an iframe that can do what they need then they've won, while with a popup they can't
... but if the popup is invisible then they still win

mkwst: chrome has put a lot of work into stopping popunders and other invisible popups. We dont think there should be invisible popups
... and if there are any it's a bug
... forcing https is less a concern than making sure particular APIs are not available to things that were delivered insecurely

bhill2: we should touch on this again in the context of COWL tomorrow
... can we define this as a kind of restriction? keep this in mind for tomorrow

mkwst: doc has a section on threat modesl and risks. look it through and see if you can make it better

npdoty: while we're on that note... should we consider other threat models or say explicitly we're not considering one.
... part of what we're doing with a network attacker model is that if users are ask for a permission they can be reasonably sure which origin is requesting it.
... but there hasn't been a lot of adoption of CSP, so it's either the obvious origin or it's someone who found an XSS bug in that origin

rbarnes: or any 3rd party legitimately included by the origin

bhill2: if you have a correct application this helps prevent exploitation; if you have an incorrect application well....

npdoty: discussed this week -- the presence of a CSP that denies inline script is indicator of secure context.

mkwst: but an attacker can inject that CSP after doing its attack

npdoty: it might be valuable to include a clause saying there are other kinds of attacks and that this is not a complete silver bullet

bhill2: we can't make the claim "this app cannot be exploited"
... not sure it provides much to make the opposite assertion

<inserted> scribe: bhill2

dveditz: if we assume invisible / popunder windows are impossible, should we specify somewhere that this should not happen?

mkwst: joachim is working on this and I would love for him to better specify this, e.g. how user gestures are tracked and consumed in chrome
... would be good to document, but practically speaking we haven't had time, there are many and it is difficult
... send jochen an email and ask

dveditz: would that be something that would be in this group or in HTML?

mkwst: there is some term in html that has a couple of points but is fairly sparsely defined. expanding on it to be useful for this would be some work

<inserted> scribe: dveditz

mkwst: there's a couple more things that I've worked with annevk on, such as what flags to add to fetch and so on

<JeffH> -> https://github.com/w3c/webappsec-secure-contexts/issues/5 "<iframe sandbox srcdoc='foo'> on a secure page should be secure" issue-5

mkwst: issue number 5: boris seemed to agree (in a long comment) "but you need a lot of tests"
... we need to figure out how to advance the spec even though it concerns things that are not in the version o HTML defined by the w3c
... I asked web-apps and they pointed at an HTML 5.1 doc that contains a bunch of things, I'm not convinced that's any more stable and I'd prefer continuing to reference the WHATWG specification.

wseltzer: I should speak up on the normative reference policy -- it is something we'll ahve to address in the w3c generally
... as more things are produced referencing more outside things. we are not saying everything has to be done in w3c so lets find a way to describe when
... things developed elsewhere are sufficiently stable and develped sufficiently openly to serve as a reference.
... maybe we can chase down some directors while we're here

mkwst: there are some things still open at this point but they are details. the general structure and outline seems complete
... the TAG was happy with it last time they looked, @@ was happy with it. matter of weeks not months to wrap it up
... dveditz filed a bug on the relation between mixed content and secure contexts

Mixed Content

<bhill2> ED: Mixed Content

mkwst: mixed content defines how content can be loaded into a page delivered over TLS
... secure context defines when content can be loaded into a secure context
... MIX used to talk about "potential secure origins" -- I've changed it to URLs and authenticated
... in MIX we can tell by the URL form itself. "unauthenticated" response is something we can tell based ont he actual response (deprecated security, or none)
... a question to dveditz: have you had a chance to review the changes to the document

<bhill2> dveditz: have not had a chance to do more than skim what you said but it seems you made the distinction so the terms are no longer confusingly similar

<bhill2> ... I raised this in behalf of others at mozilla, have to make sure this addresses their concerns as well

<bhill2> mkwst: the reason there is a distinction is that the secure context spec is not only concerned with TLS but also accepts things like file, localhost, 127.0.0.1, etc.

mkwst: the reason there's a distinction is that secure context is concerned with not only TLS but things like file:// or loopback
... and we need to define the behaviors for those that are different from those for mixed content blocking
... other than that I think the mixed content is done. maybe we have to go back to CR because I changed the definition
... I don't think they are substantive changes, but mayne someone else will. can we slip this by the director?
... the other issue is whether we want some kind of error reporting based on mixed content (raised in the session yesterday)
... now that annevk is here: TBL and others said it would be nice to know when failures were due to mixed content blocking as opposed to other kinds of network errors. what's your opinion on that?

annevk: is it actually a good idea?

mkwst: I think it's reasonable to give developers some idea when things are broken because of something they're doing wrong so they can fix it

annevk: historically we avoid saying much when we block things for security reasons. so mixed content in an iframe -- would we show a different error page?

mkwst: if it's stuff outside your context then no, but if it's stuff loaded in your own context and it fails it would help to know about it
... xhr, fetch, javascript

annevk: I think we've gotten by without this for a long time

mkwst: in the recent past we've gotten more strict about mixed content blocking (like xhr). we'd like more people to migrate and giving them better errors might help

annevk: I'm still not convinced

mkwst: things that redirect are a problematic case -- you can't just tell by inspecting your own origin

annevk: if it's just tim I'm still not convinced. it's added complexity.

bhill2: what does this give us that csp errors don't? are we going to respond right there, or is it for debugging later?
... if it's debugging then reporting seems good enough

annevk: does CSP report on this?

mkwst: if you set up your CSP to block mixed content then yes
... tim's concern was associated with doing an xhr, having it fail, and wanting to do something else whether it's an offline failure vs mixed content.

rbarnes: I'm baffled, what would you do differently?

mkwst: I'm giving you all the information I know about the use case

<rbarnes> pleased for my bafflement to be immortalized in the minutes

wseltzer: maybe it's a job for the TAG

mnot: I have to be somewhere....

annevk: if it's just the offline thing you can check navigator.online

bhill2: we can have a rule, we have to have two independent requests for a feature

<annevk> navigator.onLine

mkwst: if we can show other ways to do it I think that's sufficient

wseltzer: in all seriousness it could be helpful for the TAG to describe how things could be done securely using new features the director might not know about

npdoty: if we had better docs on webplatform.org then _any_ developer could find out

mkwst: brief context Yan broke the internet, you can do timing attacks using CSP and HSTS.

<npdoty> I hadn't realized the Firefox behavior was intentional, that's good to know

<bhill2> HSTS, mixed content, and priming

<annevk> (FWIW, CORS preflights are cached too)

rbarnes: new topic "hsts priming", priming the state like cache priming.
... because browsers learn about HSTS through headers behavior depends on whether a browser had already visited that domain or not
... proposal: if you have a non-https request that would be blocked by mixed content, but which HSTS would fix, then do a lookup (innocuous) to see if the site has HSTS.
... either the site doesn't and the request gets blocked anyway, or it does and you can safely upgrade it

yoav: is the mixed content request going out, or blocking the response coming back in?
... if it's images you still send the insecure request and then degrade the state

<annevk> mkwst: how does mixed content deal with redirects? Is an <img> fetched as http: that redirects to https: still mixed content?

<mkwst> annevk: Yes.

<mkwst> annevk: Because the redirect is non-confidential, and can't guarantee integrity.

<annevk> mkwst: and https: to http: still renders?

<mkwst> annevk: images render. they simply flag the page as being insecure.

<mkwst> annevk: in both cases you describe, the result would be mixed content.

rbarnes: you can cache "no HSTS" for a shorter time, such as the lifetime of the document
... we do need to change the order of fetch because mixed content blocking happens before the HSTS upgrade happens

mkwst: is this worth doing? what I heard from you was that this affects 1% of all potentially blocked mixed content in Firefox.
... at what level is it worth doing the work

mnot: not sure that's the right metric. if this helps people switch to https then it's a good thing

<npdoty> I think mnot is saying that it could be a larger percentage, when you consider sites that haven't upgraded to https *because* they saw mixed content failures, but would

rbarnes: the stuff that would be fixed is 0.02% of request, so it's small, but for future sites converting this would help

<bhill2> dveditz: there are two issues: changing the order of rewriting/blocking would help a lot of people

<bhill2> mkwst: but we need to do this priming to be able to do this or we have non-deterministic behavior

mkwst: we need to do priming before switching order to remove indeterminism.

<bhill2> ... and developers will have visited all of the sites they depend on so things will appear to work, but will be broken for users on first visit

mkwst: devs will have visited all the sites, so the page will work for them. users will have a broken site because they will have blocked content

bhill2: where would this live, a modification to fetch?

annevk: we could do it that way. we have a secrion on preflights, we could have a section on this

JeffH: I would expect the priming to be added to the IETF rfc XXXX because if you do this that spec is no longer stand-alone

mkwst: as far as I know no browser implements 12.4 "Disallow Mixed Security Context Loads" in the hsts spec
... fetch spec doesn't define how pinning is going to work

rbarnes: the hsts spec defines how you get the hsts information, store it, and use it

annevk: what mkwst means is that there is an upgrade step but there's nothing in fetch that says "handle the response to see if there's hsts"

yoav: would be nice if priming could be async

annevk/rbarnes: you have to block the request

yoav: I want to be able to send these priming requests ahead of time

mkwst: ...as part of the preload phase

JeffH: I should chat with you guys. I'm still concerned about references that should appear in IETF HSTS

annevk: not mentioned here, but in the html spec there's a bit about the websocket requests and hsts

JeffH: we have folklore locked up in our brain. we need to document this because we're not all here forever
... a lot of times there are missing linkages

bhill2: adjourning for lunch, resuming at 1:15

<bhill2> scribenick: bhill2

jyasskin: https://docs.google.com/document/d/1s1k7Xc3YDgbLXwcPdrYvG5ixxVVuGoYNhiZiw7rhiP8/edit
... some potentially interesting questions, if anyone is interested, here to answer questions

francois: is access to bt restricted to secure origins?

jyasskin: yes

dveditz: does this also apply to USB

jyasskin: these are similar apis, a bit different based on how devices are attached
... for nfc and usb, new protocols proposed that expose origin to remote device but block all existing devices, but bluetooth accepts as-is
... bluetooth also has a blacklist of dangerous services, which is currently keyboards and mice and FIDO devices

mkwst: based on what?

jyasskin: based on the id of the service
... no service worker access yet, can only talk when an active tab, for nfc is "frontmost" tab, which is not well defined in html spec yet

rbarnes: general concern here is overlap between this and other apis for granting access to hardware, e.g. getUserMedia and geolocation

jyasskin: only doing GATT subset for now, cameras and most audio doesn't work over this yet
... is likely that people will start doing audio over GATT, just not yet. Geolocation is totally a thing. We want that to be easier user experience than general bluetooth chooser.
... hopefully users interpret "pair" to mean "give full control of", so the user will be aware of e.g. location functionality in a device being implicitly granted
... how do we get the list of ids/services in the registry, but there is an incentive to lie about devices not listed by their authoritative creator
... this is by device class but for non-standard services is more per-device; most device makers invent their own id, but anyone can use them

<npdoty> yeah, it might be nice if we could detect when a bluetooth permission were actually a capability that matched another permission, like geolocation

https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx

<dveditz> bhill2: can bluetooth do things like usb where you plugin in a device and later it changes what it can do?

<dveditz> jyasskin: yes, they can

<npdoty> so that our privacy model is based on capabilities, rather than particular mechanisms

jyasskin: have to trust that device doesn't change the services it exposes or claimed device class after attaching
... treating that as OS level bugs that the web platform can't do anything about
... two ways to trigger prompt: user gesture to show for nearby devices
... 2nd way is related to physical web effort; a thing can broadcast a URL and any nearby browser can see that

so could a malicious device advertise itself, connect, then change itself to a keyboard?

jyasskin: going to file a bug about that

dveditz: can a web page learn what devices you have without user knowing?

jyasskin: no, only those you've paired, can't differentiate between not there and not allowed
... pretty sure model is same for nfc / usb
... some push for telling document what state the permission prompt was in when cancelled - either empty or denied
... is there a preference in this group to not do that?

<npdoty> what's the site use case that wants it?

dveditz: I would lean that way unless there's a good reason to do otherwise; it's just fingerprinting info without a compelling use case

jyasskin: come up from dev rel person, but no compelling use case yet. would be nice to respond to failures, but user has seen dialog so they know what they did

dveditz: could offer to "order one if you don't have one yet" if no devices present

annevk: how problematic is it for device to not know origin

jyasskin: very for some devices, e.g. FIDO, which is why it's blacklisted
... most other devices are not concerned about restricting to particular sources
... bluetooth group doesn't understand the concern / use case, but any way to do this would be a new service

dveditz: can same device be paired with multiple origins at the same time?

jyasskin: yes
... blacklist is standardized across all browsers

Credential Management Level 1

<rbarnes> i confess that this bluetooth thing doesn't seem like a great security trade-off to me

<dveditz> ED: Credential Management Level 1

mkwst: API is getting stable and we have feedback from credentials CG that it is generic enough to accommodate extensions for their use cases
... I am sure there will be detailed questions that come up with more implementations
... feedback is generally positive and developers like interacting with the password manager in an imperative fashion
... not happy with but can live with async form submisssion
... less happy with necessity to do multipart form submission, but that's a consequence of how fetch handles opaque formdata
... if login systems are legacy may be hard to teach it to do multipart form submission when it only understands urlencoded form submission
... may be able to get around by transforming to url search params
... but chrome doesn't implement that yet, curious if there is a better mechanism

annevk: there are other good reasons to implement that API

mkwst: then that would be another method hanging off the credential object, have to know that they have different behaviors
... don't want to go back to first principles and re-evaluate, but we have to do something

annevk: it's hard to serialize form data in other formats since it contains blobs

mkwst: if right thing is to implement the primitive that already exists

annevk: just firefox implements url search params at this point

mkwst: means we need to define an opaque variant of url search params
... if a goal is layering on top of existing login systems, probably makes sense to do this and document why to pick one or the other
... probably need to do this and file a bug for it
... working about how we allow users to choose to always be logged in
... experimenting but haven't landed any ui that we're totally happy with yet
... api is done and you can play with it behind a flag
... some outstanding questions around metadata associated with the credential, e.g. icon
... currently a URL, anne suggested might be better as a image bitmap or blob
... maybe a good idea, doesn't give us responsive images
... at this point we need: more implementer feedback, more developer feedback

annevk: what about issue 2: https://github.com/w3c/webappsec-credential-management/issues/2

mkwst: this (autocomplete) makes sense for registration cases, e.g adding address info
... not sure it's right thing for autologin
... autocomplete solves some things, but takes away some other good things.
... model in current spec prevents JS from accessing the password, this makes it impossible to deny that

annevk: can we upgrade input type=password?

mkwst: that breaks other things

annevk: can we have an opt-in upgrade to a hardened model?

mkwst: proposed a write-only attribute on form fields a while back, was no interest expressed at the time
... if there _is_ interest, idea is to add an attribute that denies read access

annevk: if we don't care about protecting password fields in general, doesn't make sense to do this
... seems it would protect against other scenarios

dveditz: how does making form fields opaque if xss can change the target of the form

mkwst: wanted this to be origin-locked to prevent that, but now that we are doing fetch integration, we have to rely on developer to do the right thing
... we could add that
... seems like a layering violation for fetch to know about this spec, but maybe opaque formdata objects always must submit same-origin
... opaque fields draft tried to taint data so that mutating form field type didn't allow an attack

annevk: but attacker could still inject a new, non-opaque field and convince user to type into that instead

mkwst: request autocomplete only deals with one side; allows you to get credentials out but not to store them

dveditz: assume we would restrict autocomplete to opaque fields...

mkwst: not clear it's valuable to go this route if only solves helps the problem
... if we need imperative storage, why would we use a completely different api to get that data back
... reason storage is important because password managers in browsers are huge piles of terrible heuristics to judge password fields and success
... miss things like XHR based logins or federations based on redirects
... imperative mechanism allows site to request help from the browser; this is the core of the value proposal from chrome password manager

jeffh: higher level, extensible API also can be used in a more smooth and abstract fashion for plugging in stronger authentication

mkwst: yes, hoping that things like FIDO will use this

rbarnes: has any discussion been had about this with the fido folks?

jeffh: we are aware of this doc

yoav: to support the importance of storing the credentials, have heard of use case where a site is interested in managing login for users where user doesn't know password
... interested in sending them a link, storing some random password on the user's device and have the login work that way

mkwst: I think storage (and sync) is a critical feature
... most password managers have a mechanism to just create a random password
... there is a bug, deferred, for this, we could re-open and put it in
... but request autocomplete is probably a more reasonable way to do this
... as you are probably trying to grab more than just a credential, and and do this all in one request
... a question is whether to care about password complexity rules at the remote endpoint
... if we need to support that, we need to specify how to define those restrictions, which I don't want to do

yoav: how can you make sure that password made it into the manager?
... does user have to agree?

mkwst: yes, of course user has to agree, this is significantly more persistent than a cookie, synced across devices, not cleared
... but user prompting is not in this spec because user agents should do what is right for their users
... what we need are implementations by browsers and developers, and developers are more important
... talked to some developers who are planning on using it once it ships

rbarnes: no current plans to do a focused implementation effort but this is broadly a direction we are comfortable with, will send some questions re: federation cases

jeffh: we should make federated identity folks aware of this

mkwst: no feedback from microsoft or apple, opera is interested

axel: followed removal of send(), not sure if I like the fetch integration, but easier to implement
... not really that complicated, much of what's needed is already there in firefox
... discussion about doing some strange crypto stuff to password before sending it, where did this end?

mkwst: currently we don't do this and don't support the use case.. don't know anyone for whom this is essential

rbarnes: if you're going to do some processing like this you're changing from an opaque object to a thing with JS that executes in a secret context that can access the data
... need to swap that paradigm, might make sense to change entirely

axel: could install something trusted that can operate on the token and transform it, would fit with how tokenization in payments world works

<JeffH> url search params = https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams ?

mkwst: think the spec is already too big, and without a concrete use case that maps to one of the things the spec is trying to do
... will be hard to find time to implement if it's not something chrome's password manager would do, so prefer not to put it in spec

<mkwst> JeffH: https://url.spec.whatwg.org/#interface-urlsearchparams

keiji: is there any possibility to have public security review as a process, since this kind of feature is very attractive for attackers, xss is common

mkwst: would love for you to read through mitigations in the spec and see if they make sense
... this should be strictly more secure than status quo
... today password manager will just fill a form for you and you can read the data out
... this is better than that
... have taken this to the TAG for review. they were supportive of the general direction and api shape

rbarnes: separation between origin and non-origin bound credentials?

mkwst: you need to talk to credentials CG
... I am skeptical about use cases but have made room for the non-skeptics' use cases if they can produce them
... some sites will have both user/password or federated login
... don't know how it will work to do that and other types in the future
... what it does now is walk up the chain to find common ancestor below base "credential"
... would like to get rid of that, not sure that I can

rbarnes: seems like a sensible thing to do
... one thing that was good about webcrypto is it didn't design any new cross-origin stuff
... origin binding is a good design principle in general

mkwst: agreed
... chrome implementation doesn't have it and doesn't suffer for it

rbarnes: in a level 2 would be easy to collapse the two types if non-origin bound uses never emerge

mkwst: origin bound might be a terrible name, could maybe "password manager type"
... picked origin bound as a not so subtle hint about what I wanted to build
... only place it has any impact is if different kinds of credentials are picked, do something sane, could hardcode that instead
... tradeoff between extension points with well-defined behavior vs. a more streamlined spec
... not entirely happy but does what I want it to do, would rather not reopen the discussion
... things I find ugly have no practical impact so don't care enough to remove them

Subresource Integrity Level 2 feature proposals

francios: first class of ideas is support for different types of resources beyond script / style
... second class is applying it to downloads

<francois> https://github.com/w3c/webappsec/issues/497

mkwst: boris had some issues with the order of applying transfer-encoding

yoav: only know after file is downloaded

francois: we already have the same thing with safe browsing

bhill2: in safe browsing the protection applies regardless of source of link, if this protection is only based on link metadata, user can just paste url into address bar and then there is no protection

francois: there are always overrides even for safe browsing, if user is determined, can use another browser that doesn't implement

bhill2: so maybe is about security considerations suggesting clear warning to users about why download was blocked

annevk: what about encoding it into the link?

dveditz: we tried a long time ago and folks didn't like the idea of messing with urls that way, but yes, you lose the integrity data when copy/pasted

timeless: is there a scheme that just has integrity only?

bhill2: there is this, but we decided against using it: https://tools.ietf.org/html/rfc6920

<annevk> bhill2: so I think that RFC doesn't allow you to embed the address

<annevk> bhill2: the authority field doesn't really tell you where to find it over HTTP

annevk: there is the well-known syntax

<annevk> bhill2: but that's a mapping to HTTP, that doesn't work for legacy download locations?

francois: another type that has been discussed is images

annevk, yes, that's a big limitation

<annevk> quite

francois: progressive rendering makes image integrity possibly unatttractive
... also lots of ways to express "images"
... progressive rendering might be a showstopper for many people

yoav: what about video/audio?

annevk: you could use fetch api to get bytes for checking in a streaming-compatible manner

<francois> https://github.com/w3c/webappsec/issues/306

francois: another type is CSS-loaded subresources, if stylesheet loads things, they are not protected

annevk: tab made it so arguments can be reused in CSS in a backward compatible manner, but no usages of that are defined

mkwst: tab is here, we can hammer that out with him before everyone flies home

francois: one thing in v1 removed was iframes. a problem anne pointed out is that iframes can be navigated, need to define what that means if an integrity protected iframe is navigated somewhere else

annevk: maybe navigation should be disabled in such a case

mkwst: use case I was thinking of was advertising where 3rd parties are responsible for serving something, want to verify that document for which you have a hash should also have integrity information

annevk: we don't do that for css

<francois> https://github.com/w3c/webappsec/issues/210

mkwst: was thought of requiring integrity on all elements of a type in a document, but dropped, and wasn't yet a way to for that on embedded content

<francois> https://github.com/w3c/webappsec/issues/16

francois: next is CSP directive to require integrity
... proposal is to use CSP to attach to a directive to require integrity for all resources that directive applies to

annevk: an injection could still add integrity, need to be in the header

<francois> https://github.com/w3c/webappsec/issues/449

bhill2: could work in concert with a signature-based approach that included a public key in the header to avoid bloating the policy

francois: which is this issue....

bhill2: there are two forms of this proposal: annotate each element with signatures (assumes page knows content in advance) vs. give a key and get a signature from the server in a header (allows dynamic content)
... is concerned about what substantial advantage dynamically signed content from a server provides over existing https semantics

mkwst: could be signed offline, but client can't tell what it's doing

dveditz: +1

<mnot> https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2F&req_hdr=User-Agent%3AMozilla%2F5.0+%28X11%3B+U%3B+Linux+x86_64%3B+en-US%29+Gecko+Firefox%2F3.0.8

bhill2: one case that has come up with in CSP is DNS, locale-specific names (e.g. google.co.jp) which server-supplied signatures could help with

<francois> https://github.com/w3c/webappsec/issues/504

mnot: are you OK with inserting content originally delivered over http into a secure context from a sharedcache?

dveditz: I like this idea

mkwst: not clear what this gives you- doesn't solve leakage problems
... no server side

mnot: you can probe with this

mkwst: and all our protections are origin-based, and you can pretend that a resource is coming from any origin
... how do we know if a script is cross-origin, if I should have access to data?

annevk: is this any worse than existing http cache issues?

mkwst: if you are caching content and it is indexed by a hash, what is the origin and how do you know if you should have access or if it should be blocked by csp?

mnot: do you adopt headers of other representation?

dveditz: script mostly doesn't care

bhill2: worker might be delivered with CSP policy

mkwst: might be useful go back to concerns documented in original spec

dveditz: if we expand to iframe, headers become much more of an issue

mkwst: can go back in time on spec to security considerations before the features were removed, and also on mailing list

<francois> https://github.com/w3c/webappsec-subresource-integrity/issues/11

<francois> is the sha3 bug

CSP level 3

<inserted> scribe: dveditz

mkwst: csp2 is basically done
... a couple things left to land in firefox, brad has a great testsuite ... on track

<JeffH> CSP lvl 3 link?

mkwst: CSP 3 is a complete rewrite of CSP2 in terms of HTML and fetch. csp2 was a little handwavy about how things worked, I hope csp3 is clearer
... spec section 4 Integrations: describes how fetch integrates into csp

<JeffH> Content Security Policy Level 3

mkwst: csp2 written in terms of requests -- pre service workers. csp3 written in terms of fetch to cope with service workers
... requests go out, through CSP. service workers can muck with it, and then the response comes back through CSP
... service worker can have its own CSP
... in the future service workers can ctalk to service workers
... Integration with fetch also does the policy parsing and puts the policy on a response object
... this was vague in csp 2, I hope it's better explained now
... (response has a csp list, we parse the policy, we do something useful with it)
... 2 hooks: should request be allowed, should response be allowed (top and bottom of fetch respectively)
... Integration with html -- all the places we have to touch to make CSP sensible.
... such as inline scripts. I've given annevk patches for some of these, some are still outstanding
... I hope this all makes the mechanics of csp significantly more clear than they were
... would be great for folks interested in the details to read this through and tell me if it makes sense or not
... number of policies that affect the document that have nothing to do with fetch (e.g baseURI) and those are described in here too
... It's nowhere near done, but done enough to start getting feedback
... Current state is "parity with CSP 2". Two new behaviors in here, but basically nothing different just making things that were implicit explicit
... one change: no longer possible to lock yourself into an insecure scheme. "http:" means "http" and "https".
... and 'self' includes websockets (ws/wss)
... the frame-src directive, deprecated in CSP 2, has been removed. I'm not sure that's a good idea
... One of the big changes is I'd like to throw away all the report functionality here. Seemed like a great idea, assuming violations didn't happen often
... but that was insanely optimistic

<schuki> servicewor

mkwst: we'd like to have a single place where reporting is defined for all kinds of things (CSP, backoff, cert pinning)
... "Not Just Error Reporting" -- will have a new name eventually

<inserted> Not Just Error Reporting -- will have a new name eventually

mkwst: https://mikewest.github.io/error-reporting/
... this should simplify CSP, just define the contents of the report and let this new spec define the mechanism
... so I'd like to remove report-uri. Folks at Google have some things they'd like to see in reports so I'd like to revisit these
... most of the things we strip from reports are actually obtainable from javascript, so people are using alternative reporting. that's showing brokenness
... other than that the doc is essentially CSP2
... some of the new things we want to do are in _new_ documents
... For example, cookie scoping, something mnot wanted
... http://w3c.github.io/webappsec-csp/cookies/
... I think it makes sense to define new things in new documents, a single feature set that can be defined and reasoned about and adopted stand-alone
... I'd like to experiment with drafting all new features this way. maybe some will move back into the monolithic doc
... you'll see in the CSP3 TOC i've divided the features into "fetch directives", "grabbag", and reporting directives

<JeffH> what was that other csp spec wrt cookie that we perused ?

JeffH: http://w3c.github.io/webappsec-csp/cookies/
... not clear any of the grabbag justify a separate document, but I'd like to think about it
... I think making the spec more modular will [improve eveyone's lives]
... if we can make smaller chunks maybe people will be more likely to implement some of them even though they can't take on the whole thing.
... small focused documents are nice, and support "checkbox oriented development"
... cookies is separate, csp pinning is separate,
... where are those?

mkwst: those are subdirectories of webappsec-csp

timeless: is there a link section in the document to those other documents

mkwst: not currently
... I talked to these lovely gentlement about setting up a registry for directives at the IETF so that's in progress

[refrencing Barry and mnot]

<mnot> Content Security Policy Directive Registry (IETF Draft, in last call)

scribe: that means the spec will have an IANA Considerations section, and new specs will have bits that say "register this new directive over there"
... feedback wanted on the module concept

francois: you said "... if only people would implement nonces and hashes..." have you thought about making CSP3 into CSP1+nonces and hashes

mkwst: maybe? I've told people those are important but I don't know that this will help?
... these are already in CSP2 so

JeffH: is the intent to leapfrog CSP2?

mkwst: I'm done with csp2 now ... I'm doing this now

bhill2: I hope CSP2 will go to rec, there's not a lot more left to do

mkwst: the testsuite is important, but that's the only part I'm interested in the process of finalizing. As part of Google of course the patent protection is impt, and some people wait for recommendation before implementing so that would be good too

francois: if CSP3 is just CSP2 rewritten then people who implement CSP 2 can also claim CSP3?

mkwst: there's some additional stuff in there, but sure
... I'm fine with publishing "CSP 2 with better explanations of the mechanism and better reporting". sure
... I don't want to work on another monolith that will take 5 years to complete

Kepeng: during the break we talked about @@

mkwst: I don't see an issue off the top so maybe we didn't file one. we should do that

<mkwst> https://github.com/w3c/webappsec-csp/issues/new

mkwst: thread starting August 27th "CSP 401 issue"

bhill2: I have a question about policy combination. has come up in the past
... in modular specs you can have
... we should require modular specs to define an intersection mechanic

mkwst: whatever directive we define will set state somewhere, and would have to define that. and whenever we see a policy we call that algorithm for that directive
... the policy per directive could be 'ignore those after the first', some way to combine them, some way to pick the strictest.

bhill2: what's the semantics of reporting in the new spec?

mkwst: the report applies to the policy. a violation in a policy goes to the reporting URL related to that policy
... it would be helpful if this document defined the considerations that modular CSP specs need to define to be part of it
... the IANA registration has some of that already
... so what do you think of francois's idea of stripping out everything unimportant and publish what we can quickly?

<Kepeng> https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0047.html

mkwst: I will take an action to strip out things from CSP 2 that isn't implemented in other browsers, keep reporting, and then other things can be left to other specs layered on top

Kepeng: what about navigations?

mkwst: I'm skeptical of specs that block navigations. I've written specs that do that, but we've seen that when there are ways to stop people from navigating people use that maliciously
... I worry about things that break interactions for users
... this would be less bad because users can just open another tab
... we can talk about it. I'm skeptical but I'm open to use cases that would be compelling

<Kepeng> https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0021.html

mkwst: file a bug on github, disuss it there too. all in one place, nice and focused

Kepeng: what about this issue https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0021.html

mkwst: mostly taken care of in the current draft
... child-src used to govern opening a new window on an origin, but we removed it
... I know doubleclick wants this, because they want to restrict where a popup add can do
... maybe worth considering because there are uses, but it won't be in child-src
... "csp-embedded-enforcement" -- most directives don't cascade into frames. would be dangerous in fact
... but if there's cooperation between embeddor and embedee we could allow it. outer says "only embed this if it complies with this policy" and then we only load children that match that policy.
... so cascades, but the potential "victim" site has to opt-in. Kind of an inverse-CORS
... Current definition in this doc is simple -- we send a request header and expect the response to match exactly
... originally I tried to be clever and use a "subsumes" policy, but that was difficult to calculate. maybe simplistic will work.
... Not currently part of the charter, but I'd like to bring it to the group.

[general mutterings of interest]

scribe: I'm hopeful this will be helpful in toning down some of the bad behaviors we see in ad networks
... any other questions or comments?

<bhill2> dveditz: what are you planning to remove?

<bhill2> mkwst: base-uri, plugin-types, form-action, maybe frame-ancestors

dveditz: what are you proposing to strip from what's in CSP2 as a "core CSP3"?

mkwst: baseuri, form action, frame-ancestors?
... maybe not much we can throw out, now angry people haven't imeplemented it
... I'd be happy with "CSP3 Core" that is a "better explained CSP2" with improved reporting

<bhill2> http://w3c.github.io/webappsec-csp/api/

mkwst: This allows a page to programmatically add a new policy to a document. Doesn't remove anything
... people today are creating and applyting <meta> tags on the fly. This is a less insane equivalent

yoav: with <meta> you know that things above it won't be covered and things below will
... and now it will be racy

bhill2: but people are effectively already doing this

yoav: as long as it's totally clear that there is a race if you do this

http://w3c.github.io/webappsec-csp/pinning/

mkwst: idea of pinning is to apply CSP to an origin, even to documents that don't have a CSP
... Google has been caught by this, for instance on error pages because they're generated by a separate system
... there are a number of models we could use. pinning, manifests, policy-uri
... we could revisit because there's better systems for reducing latency
... they kind of solve different problems
... pinning could specify a "default" -- applied everywhere and pages can layer on top.
... or pinning could be a fallback, only applied to pages that don't have a CSP

bhill2: I want this, but only the fallback form

mkwst: Google would want fallback, too
... youtube wants to move to a single monolith page, but doesn't want to define a single CSP that would cover all possible resources it might want to load
... could we have mutable policies

rbarnes: the danger is "surprise", if something changes out from under a dev

bhill2: I want the fallback to be very restrictive. if you didn't specify a policy you're in jail, and you can get out by specifying a policy

rbarnes: I worry people will approach this like CSS, adding just one thing

timeless: having things break right away is good -- then people can fix it

mnot: this is an origin-wide policy, right? couldn't have a different one for different parts of a site

mkwst: correct

mnot: the thing I'm thinking about would layer on top of this
... somewhat orthogonal to what you're doing here

rbarnes: I would be inclined to simplify. rather than have both just do the one brad likes (fallback)

mkwst: at some point I'll get time to go back and rework this
... if anyone would like to do any of this I would be happy
... if there's new stuff it would be good for them to live in other docs so we can all progress at a different pace without holding each other up

bhill2: anything else?

annevk: we didn't cover during "Secure Contexts" is the IDL. should it hide, throw?

Secure Contexts IDL

mkwst: currently it throws/rejects. I like that model but I'm open to being convinced I'm wrong

[heycam webidl issue 65]

<wseltzer> https://github.com/heycam/webidl/pull/65

mkwst: defines a secure attribute that are applied to methods
... and either rejects promises or throws for non-promises if they're used in a non-secure context

rbarnes: I have trouble believe that's a well-defined definition

mkwst: lookat the patch, hooks in right after the security check
... right after we check that you have access to the object at all we check the context. I think rejecting/throwing is better than hiding the method
... pretending the document doesn't support this when it does

annevk: especially with the document.domain thing nuking secure contexts

rbarnes: martin makes two argumentsd in the thread. [??]

mkwst: I think it's an aesthetic question. do you fall into a feature-detection regime or an error situation

annevk: two options for dealing with document.domain -- either we're a secure context and trying document.domain will throw
... or setting it destroys the secure context

<timeless> scribe: timeless

dveditz: if there's a TLS page, we define a secure-context
... how do you know if it's not one

mkwst: their proposal is that they're mutually exclusive
... do one thing, you're secure context, do the other, you're stopped

dveditz: what if you're secure context, then you ...
... oh, you're a potentially secure context
... then if you do something, you become secure context or not secure context

mkwst: can't know until you're observed
... as soon as you do one or the other

bhill2: you're a particle or a wave

dveditz: i wouldn't object if the outcome is document.domain goes away

mkwst: i hadn't thought about killing document.domain

dveditz: we'd need to measure

mkwst: i think it's too prevalent to kill
... but tying it to these features would reduce risk
... if you use document.domain you have risk
... it's totally in line w/ the rest of secure context to reduce risk
... i think it's totally worth it

yoav: any counters/usage data?

mkwst: maybe

bhill2: how does being a secure context
... an https origined thing
... that is not a secure context
... affect your ability to reach into the dom of a same-origin secure context?

<mkwst> ~4.8% of websites: https://www.chromestatus.com/metrics/feature/timeline/popularity/739

bhill2: https://evil.facebook.com, domain lower to https://facebook.com
... can i reach into the iframe?

mkwst: only if the iframe also set document.domain to facebook.com
... and we'd stop facebook because they'd want geolocation
... document.domain has to be set on both sides

dveditz: we explicitly require that because of the Princeton attack in 2001

annevk: port is set to magic value

dveditz: that's why people scratch their heads at document.domain=document.domain

mkwst: let's say 4.8% of secure websites

dveditz: is it secure? perhaps document.domain is a marker of old web site

mkwst: we can find out in 3 months
... we kill at 0.03%

annevk: it won't be that low

mkwst: setting document.domain, being secure context, and secure context mattering, is relatively low

dveditz: makes it more complicated

annevk: not really

dveditz: if we could say "you are an ssl page, document.domain throws"

annevk: usage won't be that low, we can't do that
... we can set a flag, and document.domain sets a flag, secure context sets a flag
... idl annotation will have this
... automatic

timeless: and there's testing which should verify it

mkwst: let's explore this idea
... and firefox and chrome add metrics for this
... document.domain set inside https page
... lower 0.03% then we kill it

rbarnes: +1

mkwst: adding metric in chrome will be easy, but take some time to get data
... if we can kill it, great

NextTopic

bhill2: SomethingHandling for more secure redirects
... Containers for Mozilla
... folks might not be here yet

francois: referer policy?
... I'd like to know where we're at
... are we trying to finish off the spec, go w/ what we have now
... or an opportunity to see two more policies

mkwst: my name is on the spec, i want to take my name on the spec
... jochen said he wanted to finish it
... if you feel strongly about adding features, talk to him
... we talked about Referrer Policy
... if people have feedback...

rbarnes: we discussed Timing Attacks, because mkwst fixed it

mkwst: i only fixed one
... there's a paper at the bottom
... it wasn't a timing attack, now it's a timing attack
... if you have ideas of how to fix it, let's implement it

yoav: skimming timing attack thing
... they're downloading resources, estimating sizes based on download time
... they only have to do because no one has implemented Transfer-Body-Size
... which would give them that
... or they could XHR the images and measure

annevk: that won't be exposed

mkwst: only if the endpoint opts in via cors

annevk: read up on same-origin policy

bhill2: they load resource, try to feed it to <audio> or <video>
... IE/FF fail immediately
... the time it takes to fail gives out size
... similarly scripts, AppCache
... for ServiceWorkers, you can load an opaque thing cross-origin

yoav: goal is to determine size of object

annevk: not for no cors

yoav: not for third party unless they allow origin

annevk: yes, but this is about that

bhill2: they could make the object uncompressible if they wanted to

<annevk> yoav: I recommend reading through https://annevankesteren.nl/2015/02/same-origin-policy

[ Adjourned until tomorrow ]

- DRAFT -

Web Application Security Working Group Teleconference

28 Oct 2015

Attendees

Contents