whatwg
Safelist Last-Event-ID
Per https://github.com/whatwg/html/issues/689 it can contain any header value. And it seems that a page with a cooperating server can send that header anywhere due to redirects.
Basically, use EventSource to open a connection. Get the server to set the ID. Then trigger a reconnection. Then when the server gets the header, redirect that request to wherever. That request to wherever will include the Last-Event-ID header with a value that can be controlled by the server that did the redirect.
Given that this has been the case for forever, we might as well enshrine it. (Should probably write a test to confirm though.)
Chrome definitely leaks Last-Event-ID as per the above description. I need a better tool to know whether Firefox or Safari does it as neither debugger shows much information.
Confirmed that Firefox and Safari do it though using Charles Proxy. We should just safelist the header.
@johnwilander @horo-t I'm no longer convinced that safelisting this is correct as it would allow for the kind of values that might result in script execution on the server and they could potentially bypass the length checks we now have in place. Do you have thoughts on how to fix this?
and they could potentially bypass the length checks we now have in place
Can you elaborate on this a bit more?
@yutakahirano create a same-origin server-sent events endpoint. Generate a very large ID and then end the stream. Upon seeing the very large ID, redirect to the victim server.
If we safelist last-event-id, values larger than 128 octets will be rejected by https://fetch.spec.whatwg.org/#cors-safelisted-request-header. Do you think that's enough?
The other problem is that it can contain essentially any header value byte, which historically has been an attack vector (and is why we have restrictions on the other headers now).
We'd have to apply the same restrictions as with accept.
Sounds good. Then what we need to do is to check how many site would be broken by such a change, right?
FWIW I think I can help such an investigation. I'm not sure I'll have enough time to ship the change in the near future because we'll need to talk with enterprise people to actually ship this kind of change.
FWIW I think I can help such an investigation. I'm not sure I'll have enough time to ship the change in the near future because we'll need to talk with enterprise people to actually ship this kind of change.
@yoichio is working on this.
Hi, I got a statistics. The Chrome UMA shows usage is 0.00020% and Blink API owner, or @yoavweiss said "the low usage suggests that the intent may not get a lot of pushback, assuming other browsers are planned to follow."
So I'd say the change looks safe in terms of compatibility risk.
That is great news! Here is what we need to do specification-wise:
- Update https://fetch.spec.whatwg.org/#cors-safelisted-request-header to list
last-event-idright belowacceptso it ends up sharing the same algorithm. - Update corresponding tests.
- Add a comment to https://github.com/whatwg/html/issues/7363 indicating that HTML should probably also document that certain values result in a CORS preflight. (Fixing that issue would be a nice stretch goal.)
I suspect that all implementers are on board aligning here given that it currently represents a hole in our same-origin policy protections.
cc @youennf @KershawChang