Exfiltration mitigation through connection allowlists.

[mikewest]

Developers generally desire some mechanism to mitigate the risk of data exfiltration from their sites. CSP seems like it might be a good way to provide that protection, but it is neither designed to address that problem, nor does it do so in practice.

I'd like to design an alternative approach that could be more narrowly-targeted and effective: https://github.com/mikewest/anti-exfil/ is a first pass that seems good enough to move to WICG for more discussion and evolution.

cc @yoavweiss @annevk @noamr as a subset of folks who have been interested in this area in the past. I'd appreciate y'all's thoughts (both here about migrating the repo to WICG, and on the vague shape of a proposal in the repo above).

Thanks!

[annevk]

I'm not sure I share your perspective on CSP. CSP can be consulted for each outgoing request the way it's layered on top of Fetch today and this improvement was certainly meant to capture exfiltration risks. dns-prefetch had a CSP component, but it never got implemented. The same is true for WebRTC. I think both should still be implemented.

[mikewest]

@annevk: I touched on this a bit in https://github.com/mikewest/anti-exfil/?tab=readme-ov-file#why-build-this-when-we-already-have-content-security-policy. I think there are certainly changes we could make to address CSP's coverage, and it might well be reasonable to do so. But I also think CSP's shape invites confusion about categorization and inheritance between directives that is simply immaterial to the underlying exfiltration risk that developers seem to care about. IMO, there's value in clarifying the threat model, and building a tool that addresses it more squarely.

[noamr]

The main reason I didn't feel like it was worth implementing the dns-prefetch CSP thing etc. is that it seemed futile given that we abandoned navigate-to, and navigation (e.g. with a 204) is an easy path to exfiltration, probably stronger than dns-prefetch.

Whether CSP is enough or we need a new thing (I don't have an opinion on this yet),
we would need a very strong story to replace navigate-to, and enough resources behind patching all those different places where a navigation fetch is initiated, including speculation rules etc.

[noamr]

cc @kbabbitt

[mikewest]

With the benefit of hindsight, I'd be happiest if we landed on a model wherein we defined CSP's threat model as being an effective counter to the use of resources (inlined or remote) within a given page, as opposed to a generalized defense against exfiltration. There's a lot of overlap between those goals and I don't object in principle to blending them together at the margins, but it's non-trivial to deploy CSP in a way that effectively mitigates XSS (e.g. with hashes or nonces) while also mitigating exfiltration risks (as nonces and/or strict-dynamic will enable any outgoing script request, and hashes can do the same). I think we've made a mistake by asking CSP to do both.

My suggestion is that developers who care about exfiltration risk would be best served by narrowing CSP's threat model and creating a tool whose purpose forces us to consider leaks like those noted above and in various CSP issues to be showstopping bugs. We can make that thing simpler to reason about and deploy effectively, and I think there's enough developer desire to justify the work.

[weizman]

Very glad to see this, I was advocating for this back when 656 was opened by @yoavweiss and I (w3c/webappsec#656), leading to a couple of questions:

1. The way 656 developed, I was under the impression the community isn't into seeing such a feature, I wonder what changed, could be helpful context, but not a critical question to address
2. I am not the one to answer whether this needs to be manifested via CSP or a new mechanizm from a browser internals perspective, I also do not have any strong opinion on which is better from other perspectives, both should work just fine AFAICT
3. Navigation is crucial for this to be a good feature, I endorse taking it into account
4. I do wonder about how will this behave with XO iframes. So, if origin A allows embedding origin B, and then origin B attempts to communicate with server C, which A did not explicitly allow, should the browser allow it since it's coming from B, or should the browser respect origin A's wish, being the top most frame?

[mikewest]

For this issue, I think the question is simply whether there's enough interest to shift the proposal into WICG for more discussion. I'd suggest that more detailed questions around any API's shape, spelling, coverage, etc would be better as issues filed against that repo. The explainer linked above has some thoughts about potential answers that make sense to me, but defining the threat model is certainly part of the task generally.

Also, cc @shivanigithub, who I inadvertently left off the CC list above.

[shivanigithub]

Glad to see renewed interest in this. It definitely has overlaps with the discussion in w3c/webappsec#656 . My most recent comment on that issue discusses n/w revocation in iframes. The API surface proposed there (reusing document policy) is different from this one but the underlying functionality is very similar and happy to converge on this API surface.

[mikewest]

@shivanigithub: @terjanq also has interest in some iframe-based assertion, see the discussion in WICG/connection-allowlists#1. I'm sure we can work something out. :)

[terjanq]

4. I do wonder about how will this behave with XO iframes. So, if origin A allows embedding origin B, and then origin B attempts to communicate with server C, which A did not explicitly allow, should the browser allow it since it's coming from B, or should the browser respect origin A's wish, being the top most frame?

I think the general answer is that B should be able communicate with C, because if A is able to selectively invalidate some requests it could have security implications (e.g. failing to load a sanitization library), or if it could lead to some XS-Leaks if the embedder can detect whether a request in an iframe was made. But I also can imagine that we could possibly find smarter ways to sandbox XO iframes in a securer way.

This is one of the reasons which make me think that sandboxing network requests would work better as a separate entity to CSP. In the CSP world, we would not change the spec to allow the CSP defined by a top level to affect CSPs in XO iframes. Connection-Allowlist would enable us to think about these features in the future.

[devadvance]

Context

An applicable use case for this proposal is mini apps/mini games. An increasing number of platforms offer these interactive experiences through the use of standard web platform capabilities in iframes and WebViews. I work on YouTube Playables, which is an experience in this category. Examples of similar use cases can be found on web.dev, Wikipedia, and elsewhere.

Related standards efforts and groups:

• https://www.w3.org/groups/wg/miniapps/
• https://www.w3.org/TR/mini-app-white-paper/
• https://www.w3.org/community/games/tag/open-mini-games/

Where this can help

There are two areas where this proposal can greatly improve the status quo:

• (1) Directly mitigating the risk of data exfiltration by providing a clear API surface directly intended for this use case.
• (2) Directly mitigate the risk of mini apps/games being modified over time when users expect them to be static. Practical example: a mini app/game obtains new images/data via WebRTC six months after publication.

CSP and sandboxing are helpful but incomplete for mitigating data exfiltration risks for mini apps/games.

Areas to clarify this proposal

• Exfiltration through means other than network. Examples include storage (Local Storage, IndexedDB, etc.), Broadcast Channel, and postMessage().
• Application to Web Workers and Service Workers.
• Application to WebViews.
• Application of policies depending on hosting. Extend the support to iframes connection-allowlists#1 is an example of this, where the parent doesn’t control child hosting, but is expected to successfully sandbox.

Abridged threat model

This is an abridged version of a threat model that might be helpful to consider.

Threat assumptions

• A mini app/game can be malicious, such as intentionally including user-hostile code.
• A mini app/game may become compromised, such as via loading a contaminated deep link.
• The mini app/game parent page may become compromised, such as via flaw in isolation or sandboxing, or via other malicious data.

Threat actors

• Malicious supply chain developer - a developer of a mini app/game dependency, such as a JS library, adds intentionally malicious behavior to that library, which is unintentionally included in a mini app/game.
• Malicious mini app/game developer - a mini app/game developer intentionally includes malicious behavior, such as attempts to overcome boundaries or security restrictions, in a mini app/game.
• Malicious user/player - a mini app/game user maliciously uses some part of this architecture, such as a malformed deep link, to create negative effects. Mini app/game users are anyone accessing the mini apps/games or the platform on which they are hosted.

Threat actions

• Manipulate user data - change save data, alter settings, modify mini apps/games, etc.
• Exfiltrate user data - interaction data, credentials, platform data, location information, etc.
• Update the mini app/game behavior at a later date - after some amount of time, the behavior can be maliciously altered in an unexpected, malicious, or otherwise problematic manner

[mikewest]

@yoavweiss / @cwilso: Given the above, I think there's enough shared interest in the problem space to migrate the repo to WICG for further discussion. WDYT?

[erik-anderson]

Microsoft is interested in solving this problem space; please treat this comment as another +1 for "please migrate the repo WICG."

[mikewest]

@yoavweiss / @cwilso: Friendly, pre-TPAC ping?

[mikewest]

@yoavweiss / @cwilso: Friendlier, during-TPAC ping? :)