Re: [CSP2] connect-src 'self' and websockets

<hat='individual'>
I'm also a bit skeptical about allowing 'self' to implicitly cross
protocols. Especially since WebSockets and XHR/Fetch have different
security models around allowing access to returned data.  CSP is about
restricting from where data and code can flow into an app; it seems
legitimate to not want new data flows from ws/wss endpoints into certain
resources.

On Mon, Sep 28, 2015 at 11:27 AM André N. Klingsheim <
andre.klingsheim@owasp.org> wrote:

> > From: Daniel Veditz [mailto:dveditz@mozilla.com]
> > Sent: 28. september 2015 19:19
> >
> > On 9/28/15 6:43 AM, Mike West wrote:
> > > I think this is probably worth considering as a simplification for
> > > developers, though it complicates the model a little bit by changing
> > > an origin-based comparison into a host-based comparison. Locking it
> > > to schemes with the same security properties or better might be
> > > doable (e.g. 'self' on `http://example.com` could allow
> > > `ws://example.com ` or `wss://example.com`, but 'self' on
> > > `https://example.com` would only allow `wss://example.com`.
> >
> > I do not want CSP to devolve from origin-based to host-based (we've seen
> > where that gets us with cookies), but I could live with an explicit
> > exception equating "ws:" and "http:" wrt 'self'. Ports would still have
> > to match, of course.
> >
> > Are there non-trivial services that actually run a web socket on the
> > same port as their normal web pages? If not this change wouldn't help
> much.
> >
> > As Mike said, a request for CSP3 -- we're nearly wrapped up for CSP2.
> >
> > -Dan Veditz
>
> Thank you for your swift responses and insights.
>
> The behaviour is in line with the spec, I wanted to mention it so that the
> scenario could be considered for a future CSP version. Microsoft's SignalR
> uses web sockets when available and AFAIK the default setup is to mix this
> in with the "normal" web app, so I assume this is a common scenario.
>
> I'll post an issue on GitHub. Thank you all for your great work on CSP so
> far!
>
> -André N. Klingsheim
>
>
>