Origin isolation warnings, tests and enforcement

[lidel]

Extracted from #20 (comment)

Needs

For inbrowser.link

The goal is to provide a subdomain gateway for loading websites in web browser.

Lack of isolation is a security bug. Subdomain mode MUST be enforced.

For General Availability

Good security is like water, if things are right, fishes should not even notice it.

For end users:

• We need to protect end user from subdomain misconfigurations, and at least warn them when SW gateway is deployed without proper origin isolation.
  • SW code must be smart enough to do the right thing when deployed on third-party domains, without additional configuration.
  • No shortcuts, no hardcoding "subdomain hostnames". This has to be automated, and work with any third-party domain.

For gateway Operators:

• Setup complexity should be limited to getting wildcard TLS certs.
  • Operators should know what to do/fix by just opening website via SW gateway and reading the same error as end user.

Initial design

• Before SW is handling responses, run smoke-tests for origin isolation setup
• IF subdomain setup is not available
  • Instead of loading screen, produce a loud warning to the user
    • UI should be similar to TLS or other security errors in browsers or disclaimers at public-gateway-checker or addressing docs,
    • Inform user that web features such as _redirects and Origin isolation will be missing
    • User can continue with web browsing via path gateway, but they need to explicitly click "i accept the risk" button. Path gateway should always p
• detects when we are on example.com/ipfs or /ipns path while subdomains for subdomain gateway are present (*.ipfs.example.com works)
  • Investigate fetch API, as noted in feat: add explicit support for subdomain gateways helia#439 (review)
• returns HTTP 301 subdomain redirect (example.com/ipfs/cid → cid.ipfs.example.com) to enforce origin isolation.
  • window.location.replace may be even better as it removes path URL from browser history.

Tasks

Before ETH Denver:

• fix: dynamic subdomain gateway detection #53
• do whatever quick and dirty MVP is needed to enforce origin isolation on inbrowser.link. we have subdomain setup, so we should detect being on path, confirm subdomain works, convert to subdomain, and redirect to that.
  • @lidel will give it a try

For general availability:

• detect when on example.com/ip[nf]s and either redirect to working subdomain at *.ip[nf]s.example.com or produce error page which requires user to accept the risk before they to continue browsing in path gateway mode
  • figure out how do we cache/store result of isSubdomainIsolationSupported (should be executed only once)
  • figure out how to test for regression
  • figure out if a test exists that works on subdomains without CORS headers
    • try identity CID with 1x1 px png image? (image loads don't respect cors)
• review language on error page, make it useful to both end user who wants to understand the risks and gateway operator who wants to set up subdomains correctly to fix problem for end users
• create end-to-end regression test which confirms the protections work as expected

[SgtPooki]

@lidel

SW code must be smart enough to do the right thing when deployed on third-party domains, without additional configuration.

FYI that helia-service-worker-gateway works if built with BASE_URL env var. no hardcoding required anymore. However, we could probably infer domain fairly easily if we reduce the flexibility of deployment domains (e.g. deploying on subdomain such as <subdomain>.<root>.<tld> instead of something like <root>.<tld>).

[lidel]

Yes, existence of BASE_URL means hostname needs to be hardcoded at build time, which means we can't have single trusted build which can then be deployed/cached on multiple gateways, people need to manually build to use it.

I've took a stab at removing this limitation in #53