Receivers of ranged responses must ensure all ranges come from the same underlying resource

[jakearchibald]

Say an element makes two ranged requests and receives two responses, and the serviceworker handles both. If the element accepts opaque responses (video), the serviceworker could mix opaque data from different urls, or opaque data with non-opaque data.

@sirdarckcat - could you quickly sum up an attack based on this? My brain's kinda reset and I can't think of anything bad you can do here other than lie to yourself.

+@slightlyoff

[sirdarckcat]

Sure. Does this work?
https://sirdarckcat.github.io/range/index.html

[annevk]

Hmm, synthetic 206/304 should probably be a network error for APIs other than fetch() and XMLHttpRequest.

[annevk]

Also, that doesn't work as the Range header is not revealed to the service worker since it's set in the network layer, after the service worker.

[sirdarckcat]

It is leaked, at least in Chrome.

[sirdarckcat]

Test this:
http://sirdarckcat.github.io/range/
vs.
https://sirdarckcat.github.io/range/ (you might need to refresh once or twice to make sure the SW is registered).

Here it's just demonstrating truncation as the 3 bytes it replaces are the same (Ogg), but you can construct a more complicated service worker that mixes and matches.

[kinu]

/cc @horo-t @mattto interesting, is it implementation issue then? It's possibly related to the Chrome implementation where we actually intercept requests in the network layer.

[sirdarckcat]

One thing that might be interesting is that some media fomats might have trailing checksums or something like that, which we could use to read data crossorigin byte by byte (by making 256 requests per byte - where each payload is only valid for a checksum with the last byte being what we check). This might be easier on compression formats too (we just define a byte sequence to be a sequence in a Huffman table, maybe).

[annevk]

That is only true if there are no implementation bugs at play here, right? But either way I guess range requests deserve more inspection.

[horo-t]

When the file size is big, audio/video element will send multiple requests.

• First, audio/video element sends a GET request(1).
• The user clicks the seek bar of audio/video element, the browser will send a Range request(2).

I don't understand what "network layer" means in this situation.
Are you saying that the second Range request(2) should not be handled by the ServiceWorker?

[annevk]

@horo-t no, it should be handled by the SW. What is unclear to me is what layer should be responsible for setting the range headers?

• API
• Fetch
  • Before service worker
  • Service worker
  • After service worker
  • Cache/Network

That determines how observable they are (most headers such as User-Agent and If-Modified-Since are set in the Cache/Network part and therefore not observable to service workers).

Separately we need to decide what happens with synthetic 206 responses.

@mayhemer you probably want to review this thread.

[slightlyoff]

/cc @mnot

[mnot]

@annevk I think the audio/video element (or other consumer) will be generating the Range headers in this situation.

There's another use case where they're generated in cache/network, but that's when the HTTP cache has a partial response already there and it wants to "fill it in." When that happens, it really is opaque to SW and the API, because the response is a 200 (unless the API asked for a partial response to begin with, see above).

I think this needs to be updated with the outcome of discussion at TPAC...

[mfalken]

Chrome has changed this since the bug was filed. @horo-t can correct me if I'm wrong, but my understanding is now we disallow mixing ranged responses from different origins. Furthermore, this change didn't have much to do with service worker, except that we are sure to use the response URL, not the original request URL in case the SW did respondWith(fetch(some-other-origin)). Also, we don't allow mixing of responses between network and SW-generated via new Response().

See https://code.google.com/p/chromium/issues/detail?id=505829