Hacker News Reader

Comment by comex | Hacker News Reader

Hmm, I wonder if there is anything interesting you could do by creating a Service Worker for the CDN domain. It seems that the CDN will serve arbitrary files with a text/javascript Content-Type, which is the requirement to set one up. Once created, AFAIK, such a worker remains attached to the domain until an occasional attempt by the browser to refresh it fails, and it can intercept and modify any requests from webpages on its origin, as well as navigation there. But it doesn't affect requests to that origin from other origins, like the typical <img src> from facebook.com, so it won't be able to do much.

It seems that you click "download" on Facebook images, you'll get redirected to a CDN URL. So there's that. You could see what images the user is trying to download and edit them in flight... not a big deal, but it's something.

View on HN

ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportunity for ServiceWorker exploits it's due to a JSONP endpoint that does not sanitize its callback parameter.

If you could create a valid ServiceWorker at this route, and load it inside some same-domain HTML page, then you could theoretically use it to intercept and rewrite responses to any resources on the domain under its path. Depending on how you rewrite the response you might be able to get the browser to cache the rewritten resource, which could then get used by other domains. Theoretically. I have never tested this :)

The default scope is the basename, but you can customize it, can't you?

As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, // close enough to the beginning of the file that it will work. It seems like it might be possible with the JPEG header, but of course it depends on the post processing done. (Or maybe there is some way to upload non-images?)

I seem to remember trying this (passing {scope:'/'} in the register call), and it doesn't work. Some googling seems to agree:

"Service Workers are restricted by the path of the Service Worker script unless the Service-Worker-Scope: header is set" [1]

I do wish the spec required a 'Content-type: text/service-worker', as that would effectively eliminate accidental ServiceWorkers as a threat.

[1] https://infrequently.org/2014/12/psa-service-workers-are-com...

Hmm; I don't see that in the current spec [1], and that link is pretty old. I should test it.

https://slightlyoff.github.io/ServiceWorker/spec/service_wor...

Reply on news.ycombinator.com