- From: André N. Klingsheim <andre.klingsheim@owasp.org>
- Date: Mon, 28 Sep 2015 20:26:05 +0200
- To: "'Daniel Veditz'" <dveditz@mozilla.com>, "'Mike West'" <mkwst@google.com>
- Cc: <public-webappsec@w3.org>
> 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
Received on Monday, 28 September 2015 18:26:40 UTC