Planning 2024-10-16.

[mikewest]

Hey folks, our next meeting is coming up a little more quickly than I'd realized. Let's collect topic suggestions so we can pull an agenda together.

Some things that occur to me:

1. CSP issue triage. We discussed maintenance at TPAC, and assuming we can find some folks interested in doing the work of cleaning up the spec and filing down its rough edges, it would likely be reasonable to farm out the work of triaging the existing bugs to a larger group. The group of people interested in our monthly calls, perhaps!

2. [InjectionMitigated]: The injection mitigation story we discussed is up for more discussion in Consider adding an [InjectionMitigated] extended attribute. whatwg/webidl#1440. Perhaps there's interest in digging into questions here?

3. Integrity: I'm interested in fleshing out the signature-based integrity mechanisms we discussed in the context of the broader Integrity on the Web discussion. Maybe I'll have a monkey-patch spec done by then? Maybe.

You likely also have wonderful ideas! Add them here.

cc @dveditz @simoneonofri

[simoneonofri]

hi @mikewest. thank you for the pointers. One of the hot topics at TPAC is the threat of Malicious Extensions - which, for example, make overloads of some API calls - or other actor like the old Carbanak to steal credentials.

[mikewest]

@simoneonofri: Can you point to any discussions on the topic we should pay attention to? I'd be interested to learn about any mitigations that folks might have suggested, and how those might interact with the capability model user agents generally provide to extensions.

[qabandi]

@mikewest I believe it's tied to https://www.ndss-symposium.org/wp-content/uploads/2024-327-paper.pdf - tl;dr; XSS or extension injections can be bad for websites' security. I'm assuming the push to manifest v3 is partially addressing these concerns and websites should adopt CSP to mitigate XSS. I doubt the browser can do anything here, AFAICT outside threat model. EDIT: manifest v3 comes with stricter CSP in extension context.

[mikewest]

Thanks, @qabandi! I'll read the paper. My initial reaction is similar to yours, though: it seems like extensions are going to have more power than pages by necessity (priority of constituencies).

[weizman]

Hi @mikewest, I'd love to follow up on the Realms-Initialization-Control proposal I presented at TPAC24 (minutes), to hopefully receive some signal from the WebAppSec group on what we're planning to do.

I'd like to focus specifically on what would be the right choice for an inheritance mechanizm @ WICG/Realms-Initialization-Control#10 after learning CSP doesn't really cut it.

[simoneonofri]

@simoneonofri: Can you point to any discussions on the topic we should pay attention to? I'd be interested to learn about any mitigations that folks might have suggested, and how those might interact with the capability model user agents generally provide to extensions.

@mikewest thank you. A quick analysis follows.

Background

The origin of the discussion was the paper @qabandi pointed out (thank you!). In general, it was something similar that was discussed here w3c/webauthn#1965 and to the pre-print they had sent me.

As the group has already said, and using the FIDO Security Reference, for WebAuthn, is out of the Threat Model. It is correct.

Kill-Chain

Generalizing the problem, the kill-chain is as follows.

1. Initial Access

   • The user's system is compromised (e.g., sending a link with the installation of a malicious extension, or malware); or
   • The server is compromised (e.g., a Cross Site Scripting that is either stored or reflected).

2. Execution

   • Page is altered via malicious extension or web injection (e.g., monkey patching/overloading).

3. Exfiltration/Impact

   • MiTM or Exfiltration of WebAuthn or credentials.

Conclusion

Though it's definitely a challenging problem since obviously the extension has access to the page by design. But as this is an on-the-wild issue (e.g., CyberCartel), and since the attackers ignore our threat models :) can we do anything about it?
Even just make it more complicated, or if not in this group in another, or treat it at a different level (e.g., limiting overloading for some APIs/Functions, DOMtegrity [repo],[paper])?

[mikewest]

Wrapped up the agenda at https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-10-16-agenda.md. See y'all there!