IPFS origins report wrong document.location.origin

da2x commented 3 years ago

Description

Brave returns an unexpected document location.origin when browsing on pages through the ipfs: and ipns: protocol schemes. Other properties in the location object (e.g. .protocol) are effected too.

Steps to Reproduce

Open any ipfs://hashhash or ipns://hashhash
Open the developer tools console
Execute document.location.origin

Expected result:

The function should return ipfs://hashhash.

Actual result:

It returns http://hashhash.ipfs.localhost:12345/

Reproduces how often:

Every time.

Brave version (brave://version info)

1.19.67

Version/Channel Information:

Beta only feature.

Miscellaneous Information:

This bug makes it more difficult to develop mixed HTTPS/IPFS websites as its more difficult to determine correctly what protocol scheme is being used. This might have unexpected security issues. The Chromium Extension API return the expected origin. However, some extensions get very confused when the tab.url and its document.location don’t match.

diracdeltas commented 3 years ago

cc @yrliou @bbondy

i think it's fine to have the apparent origin be ipfs:// as long as domain isolation is preserved (https://github.com/brave/brave-browser/issues/12367). ex: ipfs://foo and ipfs://bar should be treated as third parties according to the same rules as http://a.com and http://b.com.

re: what web features are accessible to an ipfs:// page, options are:

treat it like remote HTTP, which means no access to web features which require a secure context (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts)
treat it like local HTTP, which counts as a secure context (https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy)
treat it like HTTPS, which also counts as a secure context but may have some unintended side effects, such as HTTP mixed content being blocked.

i think 2 makes the most sense since IPFS documents are served locally.

spylogsster commented 3 years ago

this is how it looks now: @da2x @bbondy should we change host, hostname, href, protocol too?

bbondy commented 3 years ago

I think we need protocol updated too. @diracdeltas should hostname and host be just the CID? And href should be the ipfs path I believe

diracdeltas commented 3 years ago

if the origin changes, href, protocol, host, and hostname (possibly other properties) should change accordingly. i think host/hostname would be the CID, href should be the full URL, and protocol should be IPFS if we decide to do this.

i'm somewhat concerned that this will be need to be a bigger change for consistency. for instance document.referrer and possibly other APIs that return URLs. this could cause some security issues if not done comprehensively, see https://bravesoftware.slack.com/archives/C0145NAJP51/p1612550288046100?thread_ts=1612304914.041400&cid=C0145NAJP51.

in https://docs.google.com/document/d/156bzOF8qkieyouqnhIQzwJsCxtsTNtyVcOiClSEgeU0/edit?disco=AAAAHwJ3OFc @lidel mentioned that this change might not have much practical value, in which case i think we should hold off on it unless it's causing major webcompat or developer issues.

da2x commented 3 years ago

You can see the expected result using the URL object: new URL('ipfs://ipfshash/some-dir/file.ext#hellohash'):

URL Object
hash: "hellohash"
host: "ipfshash"
hostname: "ipfshash"
href: "ipfs://ipfshash/some-dir/file.ext#hellohash"
origin: "ipfs://ipfshash"
password: ""
pathname: "/some-dir/file.ext"
port: ""
protocol: "ipfs:"
search: ""
searchParams: URLSearchParams {  }
username: ""

Chrome/Brave notably says the origin is null whereas Firefox correctly returns the expected ipfs://ipfshash origin.

da2x commented 3 years ago

this could cause some security issues if not done comprehensively [&] should hold off on it unless it's causing major webcompat or developer issues.

That’s the current state, though. There are all sorts of places where the double origin may cause issues and confusion for developers:

ipfs.localhost isn’t in the MPSL (nor is any of the built-in default IPFS–HTTP gateways!), so malicious things can more easily set cookies or access localStorage data from *.ipfs.localhost than from a random hash-based origins, which crucially, doesn’t share a second-level domain.
window.alert and other dialogs show that they’ve originated from a cryptic and unexpected origin the user has never seen.
navigate to ipns://example.eth, the document document.cookie = "test=test; domain=example.eth", but the cookie is either rejected or unavailable because it tries to set a cookie from a third-party origin (example-eth-ipns.localhost.etc).
A page delivered on both HTTPS and IPFS may change behavior after checking document.location.protocol. Maybe it turns off ads and says “now you’re thinking with portals!” or whatever when the protocol is ipfs:.
A webapp delivered over IPFS might need to do a CORS preflight with a regular HTTPS server. (For analytics, forms, or whatnot. Not everything will be P2P on day one.) The developer will assume that the origin to put in their Access-Control-Allow-Origin response header is ipns://their-cool-domain.eth and not the hidden internal one.

bbondy commented 3 years ago

ipfs.localhost isn’t in the MPSL (nor is any of the built-in default IPFS–HTTP gateways!), so malicious things can more easily set cookies or access localStorage data from *.ipfs.localhost than from a random hash-based origins, which crucially, doesn’t share a second-level domain.

That's not true because of the work done here: https://github.com/brave/brave-core/pull/7046/files

We're looking into a different way of handling this to help address other points though.