Skip to content

Latest commit

 

History

History
147 lines (80 loc) · 13.2 KB

2020-03-17-minutes.md

File metadata and controls

147 lines (80 loc) · 13.2 KB
Raw

WebAppSec WG

Tuesday, March 17th: 19:00 UTC (12:00 California, 15:00 Boston, 19:00 London, 20:00 Berlin).

Attendees: mkwst, Artur Janc, Lukas Weichselbaum, dveditz, koto, martinmeyer, pranjal, carlosil, Santiago Diaz (saldiaz), Jun Kokatsu, Aaron Shim (aaronshim), Emily Stark, Wendy Seltzer (wseltzer)

Minutes

mkwst: thank y'all for dialing in -- interesting times, a bit of chaos. ... [agenda overview]

COOP / COEP

mkwst: without going into all the detail, there's an effort to upstream COOP into the spec. PR link below: whatwg/html#5334.

mkwst: please hop into the PR with feedback and opinions. Have some feedback from AnneVK and others, but more and wider is better. Chrome aims to ship the core of this in the 82 timeframe, probably some bugs to work out but pretty complete. Firefox has it enabled in Nightly (only) since Firefox 73. We think we have interop, but it would be really helpful for interested folks to take a hard look at the implementations and make sure we're getting this right. we think this is going to be an important security primative.

...: Cross-Origin Embedder Policy is also going in. One delta between the Chrome and Firefox implementation is the reporting mechanism which Chrome supports. Looking for feedback on whether this is useful and complete enough. Particularly non browser vendors! this mechanism is for you so your feedback is what we want.

Artur Janc: you mentioned Firefox also has an implementation of COEP. Is Dan familiar with this and the plans for shipping it?

dveditz: I am not. It's on by default in Nightly. Looking for broader agreement on the spec before moving to beta and shipping. It seems clear that this is going to be the standard, not sure when it's going to ship. We don't want to prematurely ship something.

mkwst: from my perspective we seem to have good agreement on how this works and getting this out to developers is what we need to do. Please pass that feedback on to Mozilla folks.

Jun Kokatsu (MS): Firefox and probably Chrome had problems with blob: URL. <todo: github link> w3c/FileAPI#142?

koto (Google): We need to solve blob: separately as it cuts across Trusted Types, COEP, etc. <todo: GitHub links>

aaj: The confusion may be because Jun filed a few bugs on the topic of blob:. Different consequences. Perhaps you could summarize the bug you're interested in here for non-inheritence of COOP.

jun: Problem is that when blob: URL is created, it doesn't inherit COOP. Once that URL is opened in a new tab, that new tab does not have COOP enabled. That can then be shared with cross-origin processes in some implementations. CSP: sandbox is a similar issue in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1570889).

mkwst: Is this a process model issue?

jun: No it's an inheretence issue.

mkwst: We have generally agreed (e.g. at TPAC) to have blob: inherit various security states and we just have to implement those things. I don't believe this is a problem with the design or specification of COOP/COEP themselves? That's what we're looking for feedback on right now [bug and edgecases are good, but these show blob: is broken and not a fundamental COOP design problem]

whatwg/html#4926 w3c/FileAPI#142

mkwst: the desired solution is for the blob: to have the security properties from the point it was created, and we and other browsers need to address it.

Trusted Types

koto: Chrome is aiming to launch Trusted Types in Chrome 82. We've done more work on the specification over the last few months; to our understanding we were able to compromise on a set of solutions that work for web authors and browser vendors. Worked with Anne and others to define the right point at which to convert from a Trusted Type to a string without bad side effects. We settled on hooking most of the Trusted Type logic at the WebIDL layer: whatwg/webidl#841.

...: We think we have Chrome's implementation in the right shape against which developer can code. We're looking for more feedback on this mechanism to combat DOM-based XSS. This lays the groundwork for things like sanitization APIs and other additional mechanisms of mitigating risk.

Securer Contexts

mkwst: I posted this back in February. We defined "secure contexts" back in 2015. Might be time to evolve our concept now. Originally this was all about transport -- if content was delievered securely then it could be trusted. Seems reasonable now to shift the goalposts. The vast majority of the traffic on the web is now delivered securely and secure transport is the baseline under which no modern content should go. But there's more than one aspect to security, and a single webIDL flag saying "secure" is insufficient. This doc proposes we set 3 different flags/levels, 3 kinds of threats. Mitigated by secure transport, isolation primitives, protection against injection attacks (e.g. CSP, trusted types). The goal is to define what categories should look like and what should be in them.

...: is this reasonable in broad concept? what do you think about the details? are these the right categories? are there more or fewer? Would appreciate your thoughts. Some people have filed bugs against the explainer so GitHub could be a reasonable place to give feedback. Please take a look and let me know.

Jun: I have a question about this. Let's say we want to protect against injection, like allowing sites to use WebUSB -- would be reasonable to require "TrustedTypes". But for applications that use the camera, that sites have used for years, it would be unreasonable to make a stronger requirement.

mkwst: that's a reasonable set of concerns. we need to be concerned about deployability and deprecation. We were able to shift the web away from http to https by adding requirements. But requiring Trusted Types, for instance, would be a lot more difficult for legacy apps to change to. Does seem like the right kind of thing to require for injection defense. Also seems premature to require Trusted Types since we haven't seen buy in from other browser vendors. Mozilla's position is "non harmful" but doesn't look like any work towards implementation, and I believe the same from Apple.

...: there is a tradeoff between deployability and robustness of defense. That's what this group needs to figure out.

aaj: I had a different question, tied into Jun's. The thing we've discussed in the past at TPAC, and that people were excited about, was driving web defaults, as opposed to only creating opt-in mechanisms that big companies use. I'm excited about secure contexts as a driver of the new security features we want folks to use. Requiring these features to use a set of APIs is a good motivation.

...: More directly responding to Jun, I think it's possible for browsers to make it harder for applications to "cheat" via popups or frames or etc. Browsers may need to be opinionated about discouraging a particular usage pattern. Perhaps some features gated by permissions are only available in top-level windows, or without an opener. Not sure how robust we can be, but my guess is that there's a line we can walk to encourage adoption of these features without driving developers to work around them.

koto: Regarding deployability of security features guarding secure context: this is something that individual security features need to solve for themselves. We need to address the deployability issues in TT; we want it to be widely deployable, and improve on the API as it exists. Of course, we have ideas around how to achieve that. It's important that the features guarding secure contexts are also mature enough such that they are deployable. It's a point-in-time analysis.

...: TT in particular is trivially deployable in a non-secure way (default policy that passes through strings). Need to work out the contours of what restrictions make sense.

jun: First, I like the idea of Securer Contexts. I'm not against it. That said, creating a "Secure Context" always created a new origin, so there was no direct communication channel. The new bits are same-origin, more communication channels. Still bleed through from the non-secure bits of the origin.

mkwst: that makes sense, especially for the injection portion. Quite reasonable to determine what those boundaries are and whether we can make them robust.

Fetch Metadata

Lukas: Fetch Metadata's Sec-Fetch-Dest launched in Chrome 80. We've made progress at Google using this metadata to defend against some common attacks. Some forms of XSLeaks, etc. We've deployed in Google Photos and other large products. The deployment has been great thus far. No breakage we know of, but real defense. The feature has been useful thus far, but interested in more feedback from security community around potential bypasses of our policy. More outreach to web developers necessary. Would love to get support from other vendors as well. Currently only in Chrome.

dveditz: A few days ago, Firefox landed an implementation of most of Fetch Metadata. Missing Sec-Fetch-User, needs some plumbing. All the other headers should be usable! We'd love to find out whether we're compatible.

aaj: [fireworks emoji]

Cookies

mkwst: Not something we're doing in this WG but wanted to point out two docs being discussed in the IETF HTTP group. Cookies are the only web mechanism I know that doesn't respect schemes. Was pointed out in early cookie specs as bad but it was already legacy at that point. We want to break that now. HTTP: cookies would not be delievered to HTTPS: origins and vice versa. Incrementalism spec proposes doing this same-site. Right place for this feedback would be on the GitHub repos.

mkwst: Want to completely split this -- store the scheme with the cookies. That's the second document. We ought to redefine the notion of "session" to something closer to what users expect, and want to clear insecure cookies following that notion. Again specification would happen in IETF but eager for input from the folks in this room.

Mixed Content

estark: Quick update from Chrome: shipping autoupgrades for <audio> and <video> in Chrome 80. That also shows "Not Secure" for mixed images. We aim to ship mixed image autoupgrades in Chrome 81. We'll do that gradually in the 81 timeframe to make sure we're not breaking things. So far, things are looking reasonably good.

...: Also, we published a plan for blocking mixed downloads, and aim to add it to MIX2. It's a pretty large fraction of downloads at the moment, aiming to ramp up restrictions from 82-86.

dveditz: Only same-site images?

estark: Following the rough template of the SameSite=Lax rollout. Percentage basis: 1% -> More than 1% -> Lots more than 1%.

dveditz: I haven't seen a lot of excitement about upgrading mixed images. The people who haven't fixed it are either not likely to do it, or can't. Mixed downloads (or, more broadly, insecure downloads) are more interesting for us. Not sure if we'd block or just warn, but much more interested in following suit there.

estark: Our plan is a warning for a release, then block: starting with the riskiest file types.

dveditz: Lots of executables out there.

wrap up

mkwst: lots of good content. I reiterate my desire for feeback on these proposals

wseltzer: thanks everyone for continuing to contribute in these challenging times. if there's anything W3C can do to make things easier let us know.

Agenda

Logistics