From b9231b58a0423d9a5bed8303449eba01dc19a071 Mon Sep 17 00:00:00 2001 From: Mike West Date: Wed, 16 Oct 2024 19:03:19 +0200 Subject: [PATCH] Create 2024-10-16-minutes.md Unedited, unaudited, unspellchecked. :) --- meetings/2024/2024-10-16-minutes.md | 113 ++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 meetings/2024/2024-10-16-minutes.md diff --git a/meetings/2024/2024-10-16-minutes.md b/meetings/2024/2024-10-16-minutes.md new file mode 100644 index 00000000..e3eafe3f --- /dev/null +++ b/meetings/2024/2024-10-16-minutes.md @@ -0,0 +1,113 @@ +# WebAppSec - 2024-10-16 + +**Logistics** + +* **Minutes**: (Use your W3C credentials) +* [Add these events](https://www.w3.org/groups/wg/webappsec/calendar#export) to your calendar +* **`#webappsec`** on [W3C's slack instance](https://w3ccommunity.slack.com/) + * if you haven't already joined. +* **Zoom**: + * Details at + +## Attendees + +* Mike West +* Daniel Huigens +* Dan Veditz +* Simone Onofri +* Ciara McMullin +* Artur Janc +* Yoav Weiss +* Abdulrahman Alqabandi +* Anshuman Goel +* Simone Onofri + +## Draft Agenda + +* CSP Issue Triage: We [discussed CSP maintenance](https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-09-26-TPAC-minutes.md#csp-maintenance) (briefly) at TPAC, and there are a few folks interested in helping out. Let's talk a bit about the goals and how we might organize the work. + +* Integrity: Following on our [Integrity on the Web](https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-09-23-TPAC-Minutes.md#application-integrity) discussion, there's interest in reviving the [Signature-based SRI](https://github.com/WICG/signature-based-sri) proposal. There's a [draft spec](https://wicg.github.io/signature-based-sri/) and ongoing discussion in GitHub issues that might be worth following up on together. + +* [Realms-Initialization-Control](https://github.com/WICG/Realms-Initialization-Control): @weizman suggested a followup to [our TPAC discussion](https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-09-26-TPAC-minutes.md#realms-initialization-control) to get more feedback on the proposal and dig into [inheritance](https://github.com/WICG/Realms-Initialization-Control/issues/10) specifically. + + +## Minutes + +### CSP Issue Triage + +mkwst: https://github.com/w3c/webappsec-csp/issues. 169 open today. Would be ideal to categorize these into feature requests, already-fixed issues we can close, and real issues we need to address. For the latter group, prioritization would be excellent. + +dveditz: Separate meeting from this one to agree on categorization of contentious issues, take a pass through the list together, then take a quicker pass through teh list as a larger group. + +mkwst: Separate kickoff meeting for that work? + +dveditz: Sounds good. + +aaj: Triage and first-level pass, or more involved work? Seems like more the former, and I'd like to help with that. + +dveditz: Will be both. Assume ~30% need some work, we'll need to make sure that work gets done. But first we need to understand the set of issues. Write tests, etc. Not looking to add new features at this point, just trying to make sure that what we have is accurate and works. + +Yoav: Would be good to document whatever process we're planning to operate in. What are the labels, how to approach the triage, etc? I can't commit time ahead of time, but could try to contribute when I have time. Would be good to have well-defined rules. + +dveditz: We have some labels, maybe not what we need. Should put documentation in the repo to increase clarity. Aligning on WHATWG probably makes sense. + +AI: dveditz to set up initial meetings, and Yoav to triage 3 bugs. + + +### Integrity + +mkwst: Looking for feedback on https://wicg.github.io/signature-based-sri/ and https://github.com/WICG/signature-based-sri/issues. + +Yoav: RFC9421 is more complex than we need. Could we define a subset? + +mkwst: https://wicg.github.io/signature-based-sri/#verification-requirements-for-sri [more explanation that I find hard to minute while speaking] +Signature-Input contains the list of things that will be signed +Browsers would need to define what the minimum bar should be +We could start with a subset, but we'll probably need to expand it eventually + +dveditz: https://datatracker.ietf.org/doc/html/draft-thomson-http-content-signature-00 2015 spec, did that turn into a thing? Used in Firefox for some internal stuff. This was fairly simple to implement. + +mkwst: IETF seems to have decided that RFC9421 is the thing they're running with. + +### [Realms-Initialization-Control](https://github.com/WICG/Realms-Initialization-Control) + +Gal Weizman: Looking to continue the momentum from TPAC, get more feedback on RIC. To continue the work, we're seeking positive signals from this group. Sounds like two main topics need to be addressed: + +...: 1. ddworken: Remote scripts. We feel like it would be best to start with implementation, explore integrating third-party support. + +...: 2. Inheritance. Wanted to use CSP, but the inheritance algorithm isn't sufficient to address our problem. Folks suggested Policy Container. Seems like it is going to manifest the CSP model. This doesn't cut it for us. We're evaluating a new model. + +ddworken: Why doesn't the CSP model work? + +Gal: The main problem is same-origin legacy realms: iframes. Synchronous access to main realm. CSP in certain scenarios doesn't enforce the top CSP. Same-origin iframes/popups. Someone loads a same-origin iframe from a remote resource: CSP will not enforce upon this iframe. + +dveditz: Right. CSP goes into `about:blank`, etc. It does not flow into separate documents from the same origin. That said, CSP Embedded Enforcement exists. Chrome shipped, Firefox/Safari didn't. + +aaj: I like the idea of executing JS before a realm is initialized, but I'm worried about the promise that the explainer provides that "as long as our JS runs first, and as long as we inherit, then it's safe to execute arbitrary untrusted JS on the page". Seems difficult for developers to write JS that enumerates all the maliciousnesses possible through JavaScript. Some can be done by wrapping APIs. Not sure how it works with the DOM, etc. Many attacks, side channels, and so on. Executes in the same renderer process, same address space, ends up with all same origin data. + +Gal: That's fair feedback. Explainer first: we can address the breadth of claims in the explainer. Doesn't solve all problems with untrusted code, but it's a significant step towards being able to do that. Provides infrastructure for future mechanisms to address specific problems with untrusted code. + +...: Spectre: [SES](https://github.com/endojs/endo/tree/master/packages/ses) initiative by Agoric. Confines JS code in a virtualized sandbox. They've managed to not allow code in the sandbox to access APIs useful for spectre-like attacks. If you can list the APIs useful for such attacks, you can mitigate/block access within the realm completely. Can mitigate risk of untrusted code. + +aaj: My assumption is that you need a timer and array accesses. Don't need special APIs to exploit spectre. + +Gal: SES folks forbid access to `Data.now()` and `Math.random()` specifically, and they claim that mitigated side-channel attacks. Coming at it from a TC39 perspective. Web platform is broader, DOM access, etc. But things that are dangerous in platform APIs can be monkey-patched or removed. Most significant bottleneck is how you can escape to a same-origin realm, and steal references there. + +Yoav: This is not a new capability that will make developers run untrusted code on their origin in ways they're not already doing. The hope is to improve on the status quo where developers are overriding native primitives and hoping for the best with regard to race conditions/frames/popups. This capability improves on the status quo. Obvious that moving things out of your origin is significantly safer, but there are various constraints and business reasons to run untrusted (to some extent) code on their origin. This enables that in a slightly safer way. + +Gal: Example: we've built a tool called [LavaMoat](https://github.com/LavaMoat/LavaMoat) which takes the dependencies in a package, places them within a SES sandbox such that a breach in one dependency doesn't compromise the application. We approached it this way rather than a cross-origin realm is because it wasn't possible. Dependencies are a threat to the security of the web. Sandboxing them is a great approach, but integrating code you don't trust into your origin is sometimes unavoidable. Code that needs to be integrated into the application origin, can't be elsewhere, need to harden the origin. + +aaj: I understand the motivation. It's a problem. Worlds of NodeJS and the web are slightly different, and there are differences that matter between those. But imagine a world in which you load untrusted script and want to constrain it in some ways: redefine `fetch()` to apply constraints (which applies to everything on your page; all parties have access to the same thing). We went that route when CSP was created. Allow images only from certain sources, scripts, styles, etc. No one writes useful security logic using these rules: the set of things an application needs to keep operating requires rules that are permissive enough that if you have an injection/compromised third-party, it's extremely difficult to prevent it from doing the bad things without breaking your application. Could imagine scenarios in which you have a frame where everything is disabled, but sharing a top-level realm, for examnple, seems difficult to meaningfully constrain. + +Gal: That's a good point. It's a challenge. We've handled it in all sorts of scenarios. Bottom line is that we have seen scenarios in which we've addressed this. You're right that changing APIs in a realm affects everyone: virtualization can address this concern. But whether true or not, because of supply chain development we're getting into, it's important to allow ways for multiple entities in an origin to share the origin safely. Other ideas for improvements that could work with RIC to solve this problem. Would be a good discussion, but solving this problem will be fundamental for whatever we attempt to do. Mitigated APIs: how do we give them to the good guys, but not the bad guys? If you can mutate your environment significantly, you can do it. Would require other things to deal with the problem en masse. + +Yoav: Complex rules are already being created. They're potentially incomplete, but beyond that they're racey. Completeness could come as a next step. This doesn't give you promises beyond having control over the first script that runs. Important to emphasize that. But people already doing that in the wild. + +aaj: Makes sense. Just wondering if you can scope it down to that claim: lets you run the first script on the page. Other smart things might be necessary for real security. Detaching this from the broad security claims could help. + +...: "People do this". People use CSP in ineffective ways today too. Important for the goal to be achieved in practice. Need confidence that the path we're setting developers on gives them the security guarantees. + +Gal: I'd take an action to collaborate with Artur to make sure the explainer isn't misleading. But what should the next steps be to feel confident that we can continue with webappsec not pushing this back? + +Mike: No solid answer. There's interest in the proposal and chatting to folks in more details would help. More developer interest is a great way to get browser implementers to invest in this. I feel nobody objects to the idea. We didn't talk about inheritance. CSP intentionally chose to not inherit into same origin documents. Given that same-origin documents can script each other, there's no concern there. Document.domain can mitigate that a bit, but not to a large extent. +Let's take this back to the GH repo and follow up with David and Artur and get more developer interest.