Safelist Last-Event-ID

[annevk]

Per whatwg/html#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.)

[annevk]

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.

[annevk]

Confirmed that Firefox and Safari do it though using Charles Proxy. We should just safelist the header.

[annevk]

@whatwg/security thoughts?

[annevk]

@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?

[horo-t]

Sorry, I'm not familiar with EventSource. @yutakahirano knows more than me.

[annevk]

@johnwilander @yutakahirano ping.

[yutakahirano]

and they could potentially bypass the length checks we now have in place

Can you elaborate on this a bit more?

[annevk]

@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.

[yutakahirano]

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?