Embedding-CSP header

[annevk]

This is a new header that apparently ruins CORS preflight guarantees. When are we going to stop doing that?

[mikewest]

This is a new header that apparently ruins CORS preflight guarantees.

The new header is limited to navigational requests generate from <iframe> elements, which might not be clear from the current document.

With that in mind, the client-side CORS impacts should be limited, as we're operating in navigate mode, and wouldn't give access to the bits coming back across the wire in any event. The server-side impacts are limited to sites that are using the Embedding-CSP header for some internal purpose, and don't expect user agents to send them along with requests.

When are we going to stop doing that?

When we no longer build features that require request-side signals. :)

What would you like us to do here? Is there a design you'd prefer to header-based signaling?

[annevk]

I'm well aware of the scope, but it's still a vector of sorts. Gives an attacker control over bytes in navigations.

Is the header value normalized in some way?

[annevk]

(E.g., what happens with Unicode domain input in the attribute?)

[mikewest]

On the narrow point, the value should conform to the serialized-policy grammar from CSP3, which should lock them to ASCII. I should probably be more explicit in https://w3c.github.io/webappsec-csp/embedded/#html-integration about the behavior for invalid values.

On the broader point, I agree, but I think the risk here is small, and I don't have any other good ideas about smuggling the relevant state to the embedee without adding a header. That said, it's a bad precedent, and I'm following other bad precedent. Which is bad.

[annevk]

WebAppSec should make some kind of document setting down some rules around this I think. If we generally think it's okay to bombard servers with new headers, we should have that in writing so servers know what to expect going forward.

[annevk]

Also, if you're not going to canonicalize, is the server value required to be byte-identical?

[annevk]

This also seems to somewhat go against the arguments put forward by @johnwilander in whatwg/fetch#313 to introduce more restrictions for requests that don't use a preflight.

[mikewest]

@johnwilander's arguments, as I understand them, are limited to the effect that a few well-known and well-defined headers have on servers. It's not clear to me that they apply equally to new headers to which servers almost certainly have not tied behavior.

Also, if you're not going to canonicalize, is the server value required to be byte-identical?

The current algorithm compares the parsed objects, which would not be byte-identical due to some case-folding in various places.

WebAppSec should make some kind of document setting down some rules around this I think.

Sounds like a good thing to chat about next week. :) /cc @hillbrad

[mikewest]

We neglected to talk about this last week. :/

[johnwilander]

Let's talk about this on the next conference call, please.

[mikewest]

/cc @hillbrad, as a topic for the 16th (we're having a call on the 16th, right?)

[mikewest]

This issue was moved to w3c/webappsec-cspee#3