Impact on same-origin policy about client-hints-infrastructure HOT 14 OPEN

Attaching some additional context, indirectly via @annevk:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1447631
• whatwg/fetch#903
• whatwg/fetch#736

from client-hints-infrastructure.

Looking at table 2 in the paper quoted in that Bugzilla issue, it seems like the underlying concern is that we need to make sure that overall request header sizes should be below 8KB in order for them to be CORS safe.
The specific vector described to distinguish 200 from a 400 was since fixed, but maybe there are others.

This issue seems to be impacting all new request headers, not just UA-CH, or even CH in general. e.g. Sec-Fetch-*
/cc @mikewest

We cannot place a CORS cap on the overall request headers size, as this would create its own side channel. At the same time, we can (and looks like we have) add a cap on the overall size of safe-listed headers, as 1024.

So, if I'm reading this correctly, UA-CH and other safelisted headers don't impact same-origin policy beyond running a risk of triggering a preflight, if the list gets too long. Is that correct?

from client-hints-infrastructure.

Well, it's unclear, because it's not defined how UA-CH et al work. (And there are no preflights for navigations, note.)

from client-hints-infrastructure.

We cannot place a CORS cap on the overall request headers size, as this would create its own side channel. At the same time, we can (and looks like we have) add a cap on the overall size of safe-listed headers, as 1024.

@annevk - reviving this part. Would it make sense to add a cap on the size of safelisted headers added per request? such that if someone is adding all the Client Hints, they run a risk of triggering preflights, but that won't be an issue in the typical case?

from client-hints-infrastructure.

I think coupled with Sec-* that would indeed address the concern. It's a bit unclear to me how that would work in practice. And there's a problem with navigations as those don't do preflights at the moment.

from client-hints-infrastructure.

Should we move this to client-hints-infra? This doesn't seem specific to UA-CH

from client-hints-infrastructure.

Sounds good. I think I raised this here because at the time this was about to ship in Chrome and might have been the only hints with these properties, but not sure.

from client-hints-infrastructure.

Just to catch up on discussion, it sounds like the solution is a limit on the size of the Sec-CH-* headers in the HTTP request?

from client-hints-infrastructure.

In particular, making them share a limit with CORS and Referer.

And given the multitude of headers we probably also need to take into account that currently the limit is for values only, but we probably want to account for the size of the header names as well.

(This concern might not be applicable when the server is actively requesting Client Hints. I saw a proposal of sorts for that come by at some point, but I don't know what the status is and I haven't tried to think it all through.)

from client-hints-infrastructure.

Notes from meeting with @annevk:

• Issue is the overall size of headers sent via CORS
• This is particularly an issue for Client Hints due to the large existing set and potential future growth
• Current limits don't account for header name, which can be a significant part of the size if all CH headers are requested
• The server server limit is 8k, and the referrer limit is 4k, but the length of cookies can be found by playing with the remaining space
• CH devs should focus on a patch to Fetch, and the best way might be a cookie (and sensitive header) specific budget that other headers cannot impinge on

from client-hints-infrastructure.

The concern also applies to "no-cors", you get some control over headers there as well. It essentially matters for all cross-origin requests, including "navigate", which I suppose is a novel angle that only CH headers touch.

from client-hints-infrastructure.

I could use some feedback on whatwg/fetch#1434 @annevk before adding more detail. I know the concept of 'cross-origin request' or 'serialized header size' aren't properly defined.

from client-hints-infrastructure.

Hey @arichiv, I appreciate that you're tackling this, but unfortunately I don't have the bandwidth at the moment to take this on. I believe Google has a spec mentoring program that might be suitable here. Once things are more concrete and Chrome Security has reviewed the approach, I'd be happy to take a more detailed look.

from client-hints-infrastructure.

@yoavweiss would you be willing to review? I think you volunteered to help as a spec mentor :-)

from client-hints-infrastructure.