What can be done to prevent XSS attacks against IPFS sites?

[Mithgol]

According to the Open Web Application Security Project, XSS (cross-site scripting) was the third most common Web app vulnerability in 2013.

The current security measures against XSS (such as same-origin policy or content security policy) rely on the centralized nature of the Web, e.g. different domain names mean different ownership of hostnames and thus some types of access are restricted (unless some CSP or CORS settings explicitly say otherwise).

They won't be effective in IPFS where all data seems to have the same hostname (of its Web gate such as ipfs.io) or becomes a part of the local filesystem.

Then what can be done to prevent XSS attacks against IPFS sites?

[whyrusleeping]

we set CORS headers and restrict origins, see https://github.com/ipfs/go-ipfs/blob/master/core/corehttp/commands.go#L33 and similar.

[jbenet]

We've discussed this a few other places, but we need to pull the information into here.

things worth mentioning/discussing:

• https://github.com/neocities/hshca/ (works today)
• https://www.chromium.org/developers/design-documents/per-page-suborigins (future)

[ghost]

Something that can be done by anyone, without any work on our part, is using a custom domain, as described in ipfs/notes#39

[Mithgol]

@whyrusleeping CORS is not effective if an IPFS site is attacked by a malicious script that does also reside in IPFS (i.e. an attacker does ipfs add beforehand and then uses the IPFS path of the script) and thus has the same hostname (IP address).

[edrex]

Just to unwrap this

Cause

The root cause of the vulnerability is serving unsanitized resources from mutually-untrusted sources from a single origin.

Attack

• The user accesses IPFS-deployed App A via the shared gateway.ipfs.io domain, and authorizes some privilege/stores data via that app.
• Later the user accesses (malicious) App B also via the shared gateway domain. App B is able to use the privileges / access the stored data meant for App A, counter to the user's expectation of app-level isolation. Targets include:
  • Stored user data
  • Stored credentials for remote services
  • User-approved privileges for "HTML5" APIs such as media capture, storage quota exceptions

Potential resolutions

• Enforce a separate origin per IPFS/IPNS per "root" node (root: an arbitrary node used as the base/starting point for DAG traversal). Each root represents a trust scope, since all linked objects are fixed at creation time
• Another resolution, targeting a proposed standard, would be to continue using <gateway.ipfs.io>, but set a per-root suborigin header. See Implement per-page suborigins in the gateway ipfs/kubo#651.
• The domains (or suborigins) could be <hash>.gateway.ipfs.io or similar, where <hash> is the root node hash encoded using @kyledrake's hshca.
• As @lgierth points out, many app publishers will opt to use their own domain which will also close the vulnerability for their app.

References

TiddlyWiki is a venerable distributed publishing system. Various hosting systems for TiddlyWiki content including TiddlySpace use per-application subdomains to prevent XSS attacks.

[jbenet]

@edrex can you add:

• implement per-page suborigins in all browsers

to the "resolution" part? TBL recently spoke about this, and it will get more traction. we may see it be standard as soon as next year or the following if we make a big push for it.

[edrex]

@jbenet suborigins per page or per "root"? i could see wanting to share local resources between two pages within the same root, even though "Single Page Apps" are in fashion. Especially since the same page object might get reused under multiple roots, and I think the expectation would be that each usage of a page would be isolated from the others.

How would you ensure security for legacy browsers while serving all gateway content from the same origin with different suborigin header per page (or root)?

[jbenet]

we would do it per-root.

[stevearm]

@edrex By "Enforce a separate origin per IPFS/IPNS per "root" node" did you mean having a dns subdomain (<hash>.gateway.ipfs.io)? If so, I think that solution provides:

• isolation from other pages
• transferability (the same hash can point to a new version of the page while preserving the same javascript permissions and client-side data)
• persistence (if the original publisher shuts down all their servers, the page remains functional)

I've got a bit more rambling version of this in a blog post

[kyledrake]

@stevearm I've ran into this issue as well. Take a look at https://github.com/neocities/hshca and https://github.com/neocities/hshca-proxy

Per-page origins is coming, but is still a ways off. This is a decent workaround for now.

[ghost]

I ordered ipns.name a few a days ago and will deploy HSHCA for IPNS hashes there.

[edrex]

@stevearm, yes, with separate base domains for IPFS and IPNS.

Thanks @kyledrake for thinking through and proposing hshca, it seems reasonable.

Once sub origins are sufficiently baked, we can look at how to support them without compromising security for non-supporting clients.

I'll be watching ipfs/kubo#651.

[flyingzumwalt]

This issue was moved to https://discuss.ipfs.io/t/what-can-be-done-to-prevent-xss-attacks-against-ipfs-sites/333