Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gateway] ServiceWorker could take control over gateway endpoints #4025

Closed
surma opened this issue Jun 30, 2017 · 8 comments · Fixed by #6801
Closed

[gateway] ServiceWorker could take control over gateway endpoints #4025

surma opened this issue Jun 30, 2017 · 8 comments · Fixed by #6801
Labels
kind/bug A bug in existing code (including security flaws) topic/gateway Topic gateway topic/security Topic security

Comments

@surma
Copy link

surma commented Jun 30, 2017

Version information: 0.4.10-4679f80

Type: Bug

Severity: Low. Not currently a security issue, but could become one in the future.

Description:

Take a look at QmaEtDG87K69mVR7sc48DemHpj3LqxKaQfDw6qJr2AGbmZ:

<!doctype html>
<script>
  navigator.serviceWorker.register('/ipfs/QmRcqyy8yFsVhgErobYrTcF5PSQHC36TqpA19xnBkQpFcB');
</script>

The requested ServiceWorker file is the following:

self.oninstall = event => event.waitUntil(self.skipWaiting());
self.onactivate = event => event.waitUntil(self.clients.claim());
self.onfetch = event => event.respondWith(new Response('All my base are belong to us.'));

This currently does not work for only one reason: The Content-Type on the ServiceWorker file is
not application/javascript but text/plain. If it was set to application/javascript, I could
do the following:

  1. Make someone to visit https://gateway.ipfs.io/ipfs/QmaEtDG87K69mVR7sc48DemHpj3LqxKaQfDw6qJr2AGbmZ
  2. My ServiceWorker would be installed
  3. All subsequent requests to anything that starts with https://ipfs.io/ipfs/ will return ‘All my base are belong to us.’. Even worse, since the introduction of Foreign-Fetch ServiceWorker, even websites using the CORS-enabled gateway.ipfs.io endpoint would receive the same response.

Currently, the Go FileServer implementation, which the gateway uses, does not sniff JavaScript to set a Content-Type: application/javascript header. If they ever change that, or IPFS exposes control over Content-Type, the gateway would become vulnerable to the attack above.

I think ServiceWorker are powerful and they should be allowed on IPFS. ServiceWorker are scoped to
the path where the ServiceWorker file is located. Most of the time it would be located at paths
like /ipfs/<HostID>/serviceworker.js, and therefore be in control of all requests to /ipfs/<HostID>/... which is entirely reasonable.

There’s currently no way to completely disable ServiceWorker for a domain or a path, so I created an issue on the ServiceWorker spec. For the time being, my suggestion is to sett the header Service-Worker-Allowed: /_jail on all requests that match ^/ip[fn]s/[^/]+$ on the gatway.

@Kubuxu Kubuxu added kind/bug A bug in existing code (including security flaws) topic/gateway Topic gateway topic/security Topic security labels Jun 30, 2017
@whyrusleeping
Copy link
Member

Hah, very interesting. Thanks for the detective work here :)

We will definitely keep this in mind when moving forward with service worker addons

@daviddias
Copy link
Member

Thanks for converting the report into this issue and for opening w3c/ServiceWorker#1165 as a proposal!

@whyrusleeping whyrusleeping added this to the Ipfs 0.4.12 milestone Aug 31, 2017
@whyrusleeping
Copy link
Member

Putting this on the 0.4.12 milestone so we give it more attention. I know we want to start doing more with service workers and content types, so its important to keep this in mind and follow up.

@surma
Copy link
Author

surma commented Aug 31, 2017

Happy to help review any idea y’all have in the general area of Service Worker :)

@Kubuxu
Copy link
Member

Kubuxu commented Nov 6, 2017

Solution would be to block requests to /ipfs/Qm...AAA with Service-Worker: script header.
Requests to /ipfs/Qm...AAA/xxxx.js should be allowed.

See w3c/ServiceWorker#1165 (comment)

@surma
Copy link
Author

surma commented Nov 6, 2017

I like that solution.

@Kubuxu Kubuxu modified the milestones: Ipfs 0.4.12, go-ipfs 0.4.13 Nov 6, 2017
@olizilla
Copy link
Member

olizilla commented Feb 9, 2018

Just for clarification for anyone who is new to Service Workers (me), I was initially confused as to why SWs path scope rules wouldn't solve this, but I see now that it doesn't

If you register a SW from:

/ipfs/QmHash/sw.js

then the scopeUrl is /ipfs/QmHash/ and your SW can only manipulate requests for resources below that hash, which is good and proper. But if as in the example you register a SW directly from:

/ipfs/QmHash

and the gateway starts to serve files like that with the correct js mime-type where appropriate, then the browser will have loaded a js file called QmRcqyy8yFsVhgErobYrTcF5PSQHC36TqpA19xnBkQpFcB from the path /ipfs.

In ServiceWorker terms, the scopeUrl ends up being /ipfs/, and that means all other requests for files served from the gateway end up under the control of a potentially malicious ServiceWorkers control.

Of note, path based scopes for service workers were, at least partly, introduced to allow usecases where a service hosts content from multiple users in sibling directories, see: w3c/ServiceWorker#468

Also of note there is an active issue discussing the service worker path scope trailing slash issue and sub origins here: w3c/ServiceWorker#1272

@lidel
Copy link
Member

lidel commented Aug 7, 2018

Just for the record, another vector for this could be future support for returning content-type stored in "Extended Attributes" of ipld/legacy-unixfs-v2#11

@momack2 momack2 added this to Inbox in ipfs/go-ipfs May 9, 2019
lidel added a commit to ipfs/js-ipfs that referenced this issue Dec 17, 2019
Introduces hardening proposed in:
ipfs/kubo#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Stebalien pushed a commit that referenced this issue Dec 17, 2019
Introduces hardening proposed in:
#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Stebalien pushed a commit that referenced this issue Dec 17, 2019
Introduces hardening proposed in:
#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
pontiyaraja pushed a commit to pontiyaraja/go-ipfs that referenced this issue Dec 27, 2019
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Stebalien pushed a commit that referenced this issue Jan 17, 2020
Introduces hardening proposed in:
#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Stebalien pushed a commit that referenced this issue Jan 17, 2020
Introduces hardening proposed in:
#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Stebalien pushed a commit that referenced this issue Jan 17, 2020
Introduces hardening proposed in:
#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Stebalien pushed a commit that referenced this issue Jan 17, 2020
Introduces hardening proposed in:
#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
lidel added a commit to ipfs/js-ipfs that referenced this issue Feb 1, 2020
Introduces hardening proposed in:
ipfs/kubo#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
alanshaw pushed a commit to ipfs/js-ipfs that referenced this issue Feb 3, 2020
Introduces hardening proposed in:
ipfs/kubo#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
alanshaw pushed a commit to ipfs/js-ipfs that referenced this issue Feb 3, 2020
Introduces hardening proposed in:
ipfs/kubo#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 6, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 6, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 6, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 8, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 8, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 8, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 8, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 8, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
ralendor pushed a commit to ralendor/go-ipfs that referenced this issue Jun 8, 2020
Introduces hardening proposed in:
ipfs#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
hacdias pushed a commit to ipfs/boxo that referenced this issue Jan 27, 2023
Introduces hardening proposed in:
ipfs/kubo#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>


This commit was moved from ipfs/kubo@115b2ba
hacdias pushed a commit to ipfs/boxo that referenced this issue Jan 27, 2023
Introduces hardening proposed in:
ipfs/kubo#4025 (comment)

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>


This commit was moved from ipfs/kubo@455e498
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) topic/gateway Topic gateway topic/security Topic security
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

6 participants