Consider treating non-special schemes like local schemes

[shekyan]

It most likely was discussed already, but I think it is worth clarifying:
currently, any non-local (e.g. none of "about", "blob", "data" or "filesystem") scheme is treated the same way by matching algorithms, meaning that default-src * allows all kinds of schemes like "carousel", "itms-apps" etc, unlike local schemes that need to be opted-in.
I propose any scheme that is not a special scheme be disallowed by a wildcard source expression (*).

[michaelficarra]

👍 I don't think there's a use case for allowing a scheme that the policy author wouldn't know about ahead of time.

[mikewest]

I think I can get behind this (with the practical caveat that we don't have a ton of control over the contents of things loaded from interesting schemes, so the language about inheriting policy will be pretty toothless).

Would you like to put together a PR?

[annevk]

If we are going to safelist schemes it seems better to safelist "network schemes" rather than "special schemes". Note that by the time WebSocket reaches CSP the scheme will be "http"/"https" already.

[shekyan]

I am in favor of safelisting "network schemes", but missing "ws" and "wss" is confusing. Can you please clarify:

Note that by the time WebSocket reaches CSP the scheme will be "http"/"https" already.

[mikewest]

But what about gopher:?! :)

Defining * as http: https: ftp: seems reasonable. And I agree with you, @annevk, that ws and wss are already taken care of by the time we hit the CSP checks in Fetch (by https://fetch.spec.whatwg.org/#concept-websocket-establish). I don't think there's any risk in treating connect-src https: as allowing websocket connections to any wss endpoint, actually, though that's not the way Chrome or Firefox currently works.

@dveditz, @ckerschb: Thoughts about changing Firefox's implementation?

[shekyan]

Interesting. @mikewest, does it also imply that connect-src wss: will allow HTTPS connections to any endpoint? Otherwise, if we decide to ignore ws/wss schemes, the change will break existing policies that only allow WebSocket connections and nothing else.

[mikewest]

Yeah. Those would break. We'd either need to special case them, or break them. If we think that's the right route to go, we can add some metrics to see how often such policies are present. I bet it's not particularly often.

[shekyan]

As Fetch says:

There is no real reason for WebSocket to have distinct schemes, it's a legacy artefact.

which doesn't make CSP the first blaming target on the list:) . I am in favor of deprecating "ws"/"wss" in CSP.
@mikewest , can I help with adding metrics or it's proprietary land?

[mikewest]

@shekyan: File a bug against Chrome; we can talk about how you might add metrics there. That stuff is all open.

[shekyan]

Filed a tracker at https://bugs.chromium.org/p/chromium/issues/detail?id=602717

[hillbrad]

I think we want to preserve forward compatibility and the ability to have
an extensible web platform. It seems the germane distinction for CSP is
whether we can express a source expression which identifies a group of
resources within the scheme with a shared security principal (e.g. an
Origin). The schemes that are opted out are those which are explicitly
defined as having a unique security principal for each resource. I'm not
sure what the right way to identify further app-specific GUID schemes is,
that doesn't also preclude future evolution of the platform in a benign way.

On Sun, Apr 10, 2016 at 8:11 PM Michael Ficarra notifications@github.com
wrote:

👍 I don't think there's a use case for allowing a scheme that the policy
author wouldn't know about ahead of time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#69 (comment)

[annevk]

@hillbrad could you maybe try to restate that? I have a hard time following the point you are trying to make.

[mikewest]

I think this is settled in the spec and in Chrome/Firefox.