search

w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
207 stars 78 forks source link

Remove mentions of the ws\wss schemes in CSP #332

Open andypaicu opened 6 years ago

andypaicu commented 6 years ago

The fetch spec converts the websocket schemes into http schemes:

https://fetch.spec.whatwg.org/#concept-websocket-establish

Which means by the time CSP checks the request, the URL will be http/https.

We should just have a note about this behaviour and remove other mentions of the ws/wss schemes.

Linked comment: https://github.com/w3c/webappsec-csp/pull/331#issuecomment-421427404

mikewest commented 6 years ago

This is true! But it's confusing! And I'm not sure the behavior it implies for connect-src https://example.com matches Chrome's existing behavior (or Firefox's!)!

It's certainly worth cleaning up, but I think that will actually require behavioral changes in CSP. That might be reasonable to do, but it's a bit larger than just removing mentions of ws or wss.

annevk commented 6 years ago

That doesn't seem entirely accurate as the behavior changes, standards-wise, have already been made. To CSP ws/wss are a no-op at this point as it'll never get them passed.

andypaicu commented 6 years ago

I don't think the scheme change has any impact or implication on connect-src. Currently CSP decides based on the request's destination and initiator which directive is relevant for a request: https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request

The only thing I see it affecting should be this auto-upgrading scheme logic from the scheme-matching algorithm: https://w3c.github.io/webappsec-csp/#match-schemes

The intent here was to allow upgrades from un-secure to secure version of the scheme (aka ws=>wss and http=>https) as well from ws schemes to http schemes.

This will allow matching backwards from http schemes to ws schemes.

So basically connect-src https://example.com will allow a websocket wss://example.com (which is probably what @mikewest was referring to) whereas, before the fetch spec change it would have been blocked.

As @annevk notes, this change has already occurred, according to specs and there is nothing in particular that needs to change in CSP other than perhaps adding a note.

april commented 5 years ago

AFAIK, Firefox still shows wss://... in its CSP reports - should they be changed to show the blockedURI as https://...?

annevk commented 5 years ago

That seems more truthful in a way, though CSP has enough information to effectively undo the change Fetch has made and go back to wss://....