CSP and data exfiltration

[yoavweiss]

CSP currently has a few gaps that prevent it from being a useful anti-exfiltration mechanism. https://www.w3.org/TR/CSP3/#exfiltration hints that preventing data exfiltration may be a goal, but it's not very explicit.

I'd like to gauge folks' willingness to make anti-exfiltration an explicit goal. If we were to take that route, we'd probably want to:

• Have control over dns-prefetch and preconnect, potentially with a superset of all directives.
• Revive a variant of navigate-to that would prevent exfiltration through navigations
• Have control over WebRTC and WebTransport, somehow.
• Modify the way iframes can be navigated to any resource on the origin to shake off CSP restrictions.
• <other things I may be missing>

That's a bunch of work, and I'm not suggesting we have to tackle all of it in one go. But I want to understand if this is something that the group is interested in, directionally.

[yoavweiss]

^^ @weizman - who helped me formulate the above list

[weizman]

I would love to see (and help with) progress on this matter, we've been worried about data leakage for years and it could genuinely help ship safer web applications.

[ArcEglos]

I just wanted to chime in and also voice excitment on the possibility of this gaining traction!

We're making heavy use of CSPs to protect against sandboxing in our artifacts feature on claude.ai. Having these gaps closed from a CSP side would really help us feel better to build more powerful features on top of it.
If there is anything we can do to help make this happen I think we'd be happy to contribute and support.

For Context:
Artifacts is our feature that (among other things) allows people to run bits of code authored by Claude - our AI model. It runs it inside a sandbox built specifically for this using iframes and CSP. Obviously protecting against exfiltration is important for this usecase, as the code written by Claude could include sensitive information.

[weizman]

I just wanted to chime in and also voice excitment on the possibility of this gaining traction!

We're making heavy use of CSPs to protect against sandboxing in our artifacts feature on claude.ai. Having these gaps closed from a CSP side would really help us feel better to build more powerful features on top of it.
If there is anything we can do to help make this happen I think we'd be happy to contribute and support.

For Context:
Artifacts is our feature that (among other things) allows people to run bits of code authored by Claude - our AI model. It runs it inside a sandbox built specifically for this using iframes and CSP. Obviously protecting against exfiltration is important for this use case, as the code written by Claude could include sensitive information.

Say @ArcEglos, for such use case, wouldn't running such untrusted code within a sandboxed iframe cut it?

If it runs within such an iframe that has no origin, the ability to leak information from within it would be pointless because there won't be any sensitive information there (because everything that's sensitive is stored within the origin of your app, to which sandboxed code won't have access to).

Can you elaborate on your use case? As in, why isn't this enough for it?

[arturjanc]

I'll share my take because this is something that's been discussed in WebAppSec several times (e.g. see this old thread) and keeps coming up :)

At a high level, I agree that it would be nice if we had a mechanism that prevented data exfiltration from attacker-controlled documents. However, the challenge is that CSP in its current shape is not it (and will arguably not be sufficient even if we address the issues we mentioned above), and - more broadly - that providing any meaningful guarantees would require solving multiple open problems that we currently don't have solutions for.

To see why, let's first establish that the only scenario in which robust exfiltration protections have value is when the attacker can execute JavaScript in the context of a document with some sensitive information we want to prevent them from leaking to the outside. If there's no injection / untrusted code execution in the first place we don't need to constrain the ability of the document to make external requests (except to prevent otherwise well-meaning developers from accidentally loading resources from untrusted destinations, which existing CSP directives already do a good enough job of restricting). If there's an injection but the attacker isn't able to execute scripts (e.g. because there's a strict CSP which prevents JS execution), the attacker may be able to make external requests, but generally won't be able to leak the secrets from the page because they will not have the ability to take these secrets and include them in the external requests they make. (There are a few caveats here, such as dangling markup attacks and CSS-based exfiltration, but let's put them aside because they can be solved with CSP and default changes to browsers.)

So, assume the attacker can execute JS in the context of a document with secrets that we want to protect and that the attacker's JS can access. The problem is that preventing this code from leaking this secrets would require all of the following:

1. Covering all possible network requests sent by the browser by CSP directives; this requires adding controls on prefetches/preconnects, navigations (navigate-to), lower-level network APIs, etc., as @yoavweiss mentioned above.
2. Restricting the use of JS APIs that can be used for cross-document communication. This means restricting things like postMessage, BroadcastChannel, but also the ability to set window.name, document.cookie and possibly other client-side storage APIs (localStorage, IndexedDB, etc). Some of these attacks could be addressed if the document with the attacker-supplied code is hosted in a unique origin only used once, but that assumes developers will know that this is a requirement and properly implement their origin segmentation logic.
3. Addressing all browser-side covert channels. There are many known ways to transmit information to other documents opened by the user (e.g. attacker-controlled documents from different origins loaded in separate tabs/iframes); this includes transmitting data by modulating the use of shared resources such as CPU, GPU, bandwith, memory or disk in ways that are observable cross-origin, or exhausting browser-level limits (e.g. using up the global limit of network sockets). These seem complex, but pretty much all of them have known PoCs.

While I could imagine us doing (1) and (2) - likely with non-trivial implementation costs - we don't have any realistic solutions for (3). This is important because preventing exfiltration is unfortunately an all-or-nothing proposition. If we fix all of these channels except one, it will be insufficient at achieving the security goal we're discussing here. Given the amount of work necessary on various fronts, I'm worried that it would be quite difficult to get to a point where we meaningfully prevent exfiltration.

Finally, the challenge is that even if we built the necessary directives into browsers, a lot of the security will hinge on developers' adhering to a number of application-level constraints outside of the control of CSP (e.g. using unique origins, ensuring that there are no sibling iframes to which content could be postMessaged, enabling Cross-Origin Opener Policy, etc). We know that CSP is very easy for developers to misconfigure by crafting policies that look reasonable, but provide no real security benefit; I'd be worried that we'd create such a situation here, where it would require world-class expertise to enable anti-exfiltration defenses that aren't trivially bypassable.

Instead, what I'd suggest is to look at special-purpose APIs, similar to e.g. Fenced Frames which have exfiltration defenses as an explicit design goal. AFAIK Fenced Frames don't aim to protect against covert channels, but it could make sense to see if we could add any relevant defenses there.

[mozfreddyb]

I will keep my comment short and say that I subscribe to @arturjanc's worry. CSP might indeed not be the best place: Adding restrictions to a document seems like an error-prone approach. Especially as the APIs available are going to be a moving target.

I'd would much rather like us to explore an environment, where there's a limited allowed set of APIs that can be expanded according to a specific threat model with strong security guarantees.

You'll have to pardon my ignorance @arturjanc, but is that what Fenced Frames is supposed to be?
Can you maybe go into some details why Fenced Frames wouldn't have to deal with the challenges you described for a CSP-control against data exfiltration?

[arturjanc]

Can you maybe go into some details why Fenced Frames wouldn't have to deal with the challenges you described for a CSP-control against data exfiltration?

In a nutshell, the goal of Fenced Frames is to prevent a collaborating embedder and fenced frame from exchanging information with each other: "The fenced frame enforces a boundary between the embedding page and the cross-site embedded document such that user data visible to the two sites is not able to be joined together." - this implicitly does a lot of the things we'd want in a solution for preventing exfiltration.

There are a lot of details, but the main properties of fenced frames are outlined in the design, privacy and security sections of the explainer.

As is, Fenced Frames aren't a solution for data exfiltration because they allow network communication (though IIRC the original version of this proposal disabled all network requests) and don't protect against covert channels. But I could imagine incremental / opt-in changes to Fenced Frames that would get us closer to providing exfiltration protections.

[shhnjk]

I'd would much rather like us to explore an environment, where there's a limited allowed set of APIs that can be expanded according to a specific threat model with strong security guarantees.

FYI, we do have this environment for a few years now, with WASM and importObject (see https://github.com/shhnjk/as-sec). It's just that it has to be compiled before use.

[ArcEglos]

I just wanted to chime in and also voice excitment on the possibility of this gaining traction!

We're making heavy use of CSPs to protect against sandboxing in our artifacts feature on claude.ai. Having these gaps closed from a CSP side would really help us feel better to build more powerful features on top of it.
If there is anything we can do to help make this happen I think we'd be happy to contribute and support.

For Context:
Artifacts is our feature that (among other things) allows people to run bits of code authored by Claude - our AI model. It runs it inside a sandbox built specifically for this using iframes and CSP. Obviously protecting against exfiltration is important for this use case, as the code written by Claude could include sensitive information.

Say @ArcEglos, for such use case, wouldn't running such untrusted code within a sandboxed iframe cut it?

If it runs within such an iframe that has no origin, the ability to leak information from within it would be pointless because there won't be any sensitive information there (because everything that's sensitive is stored within the origin of your app, to which sandboxed code won't have access to).

Can you elaborate on your use case? As in, why isn't this enough for it?

The main issue is that the code itself can be sensitive or have access to sensitive information. E.g. claude could based of the information in the prompt write code that has some sensitive bits inlined into the code as strings that it then sends to the outside world when the code is executed - for example by making each of these strings a query parameter on a prefetch html element.
Also we'd ideally want to allow this untrusted code to still take specific well-defined actions (through a properly limited API between the contexts) in the outside world - e.g. reading in data from it - that could increase the amount of sensitive data in the sandbox a lot.

These scenarios are somewhat unlikely to happen by user error but there are certainly attack chains imaginable that lead to such a result.

To your points @arturjanc:

While I could imagine us doing (1) and (2) - likely with non-trivial implementation costs - we don't have any realistic solutions for (3). This is important because preventing exfiltration is unfortunately an all-or-nothing proposition.

I do agree with the characterization of these three categories. Thank you for seperating them out so nicely! But I do think that there is significant value to be had by just solving (1) and (2), because it still makes the attack chains a lot harder to execute depending on the specific circumstances and reduce the surface, which is helpful as a mitigation. At the end of the day security is often a question of lowering the probability to an acceptable but non-0 level.

I'd be worried that we'd create such a situation here, where it would require world-class expertise to enable anti-exfiltration defenses that aren't trivially bypassable.

This is certainly a relevant worry. It's already quite complicated currently and this would certainly make the list of things you can forget about longer. However, I would argue that it would not make it worse than the current situation and would still be a win.

However, my counterpoints are ONLY relevant if the two worlds to choose between are improvements to the CSP vs the current state. If there is a third world where we have other robust mechanisms to stop such exfiltration that would of course be even better!
I am, however a bit worried in that this sounds like a multi-year project to get something like this on the road, while to me - and I say that very much as an outsider, so please apply many grains of salt to this - it feels like targetted improvements to the CSP could have some value (albeit less of it) faster.

@shhnjk

I'd would much rather like us to explore an environment, where there's a limited allowed set of APIs that can be expanded according to a specific threat model with strong security guarantees.

FYI, we do have this environment for a few years now, with WASM and importObject (see https://github.com/shhnjk/as-sec). It's just that it has to be compiled before use.

One question from someone not doing a ton of things with wasm myself yet: This would still require to run untrusted code outside of this primitive for doing DOM interactions, did I get this right? Or did I miss something on how this interacts

[shhnjk]

I'd would much rather like us to explore an environment, where there's a limited allowed set of APIs that can be expanded according to a specific threat model with strong security guarantees.

FYI, we do have this environment for a few years now, with WASM and importObject (see https://github.com/shhnjk/as-sec). It's just that it has to be compiled before use.

One question from someone not doing a ton of things with wasm myself yet: This would still require to run untrusted code outside of this primitive for doing DOM interactions, did I get this right? Or did I miss something on how this interacts

Right, the WASM environment does not have access to the DOM or network by default (which provides the security guarantees). You can then expose arbitrary APIs to WASM via inportObject (see this inportObject code and WASM code).

[arturjanc]

But I do think that there is significant value to be had by just solving (1) and (2), because it still makes the attack chains a lot harder to execute depending on the specific circumstances and reduce the surface, which is helpful as a mitigation.

I empathize with this view, but the problem is that browsers would need to invest significant resources in implementing capabilities to restrict various existing behaviors -- and developers would need to invest in deploying these restrictions in their services -- to achieve a security property that stops holding as soon as the user has any attacker-controlled document open in their browser. This is generally not how we want the web security model to work - we need to have robust boundaries and assume that the user may be concurrently viewing untrusted content (also because it's often easy for a malicious site to navigate the user to chosen endpoints on the victim site and set up the right conditions for exfiltration).

This would be less of a concern if the primitives existed in the platform, or were trivial to add, and it was just a question of getting developers to use them. But the necessary CSP knobs here are non-trivial to build and in some cases run into concerns (e.g. navigate-to had some issues with redirect-based XS-leaks); so it would require a big effort and cross-browser consensus, which makes the security "ROI" here somewhat dubious.

I am, however a bit worried in that this sounds like a multi-year project to get something like this on the road, while to me - and I say that very much as an outsider, so please apply many grains of salt to this - it feels like targetted improvements to the CSP could have some value (albeit less of it) faster.

I actually think it may be the other way around here, for a number of reasons. CSP is a very general mechanism usually enabled as a mitigation against script execution in the event of injections; it's commonly applied to an entire service/webapp and requires configurability that allows creating policies that will be adoptable in existing content (e.g. fine-grained allowlists for each directive). It's also overloaded with complexity and hard to extend for a variety of unfortunate reasons.

The use cases where we'd benefit from exfiltration protections are very different: it's usually about applying restrictions to a separate document (e.g. iframe) where an attacker can execute scripts that have access to some sensitive data. To achieve exfiltration protections here we don't need a dozen different configurable settings, we just need that context to completely turn off the three main communication channels we're discussing here (network requests, local communication/storage APIs, covert channels), which is simpler conceptually than building fine-grained controls for all these things.

So, counter-intuitively, I'd expect a new special-purpose API to be a more promising approach here, largely because it avoids the baggage of having to integrate with CSP. I'm not sure how easy it will be to sell browser vendors on this idea, but I'd expect this to be on par with selling them on extending CSP :)

[ArcEglos]

Thanks a lot for the wider context of these things! Super helpful to calibrate things in my head.

I guess the way to go about convincing browser vendors about such new API is not in this github issue? If that assumption is correct I'd be super thankful if you had any advice on how best to approach working towards this - assuming that there might be some possibility of us being willing to contribute/sponsor efforts.

[dveditz]

CSP currently has a few gaps that prevent it from being a useful anti-exfiltration mechanism. https://www.w3.org/TR/CSP3/#exfiltration hints that preventing data exfiltration may be a goal, but it's not very explicit.

At one point anti-exfiltration was an explicit NON-goal!

[arturjanc]

I guess the way to go about convincing browser vendors about such new API is not in this github issue?

I think it could make sense to discuss this at one of the upcoming WebAppSec meetings (possibly at TPAC in a week or so) and see what folks think about an anti-exfiltration web security primitive. /cc @mikewest who might have thoughts :)