Block opaque 416 responses to range requests

[yoshisatoyanagisawa]

What is the issue with the Fetch Standard?

The current Fetch Standard specifies that for an opaque response with the range-requested flag set, but without an originating Range header in the request, a 206 Partial Content status code should result in a network error. This is a crucial security check designed to prevent XS-Leak attacks that could reveal resource sizes.

However, this check is limited to 206 status codes and does not apply to 416 Range Not Satisfiable responses, which are also used for failed Range requests.

[annevk]

I see, revealing that we might be out-of-range is also information. And I see that it also reveals the size of the resource. Nice find.

[annevk]

@jakearchibald if I remember correctly you wrote tests for 206. Would it be easy to augment those to also cover 416?

[yoshisatoyanagisawa]

I see, revealing that we might be out-of-range is also information. And I see that it also reveals the size of the resource. Nice find.

It is not me but the crbug.com/474435504 was filed.
I have drafted the naive spec fix: 4e32209

[annevk]

Oh thanks, I had also created a fix here: #1907. 😊

[yoshisatoyanagisawa]

Thanks for working on it. It looks much better than my PR. I will withdraw it.
Also, as you can see, Chromium has implemented the change for this.

[annevk]

@yoshisatoyanagisawa I can't see the Chromium change. Are you also adding (WPT) tests?

[valenting]

I think this change makes a lot of sense.
Right now Firefox completely bypasses service workers for cross-origin requests containing a range header, but we're planning to address this in bug 1465074.

[yoshisatoyanagisawa]

@yoshisatoyanagisawa I can't see the Chromium change. Are you also adding (WPT) tests?

Unfortunately, no.
https://chromium-review.googlesource.com/c/chromium/src/+/7453440 is the Chromium change. I am not sure if the access is restricted.