Origin isolation warnings, tests and enforcement
Opened this issue · 2 comments
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
- Instead of loading screen, produce a loud warning to the user
- 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 ipfs/helia#439 (review)
- Investigate
- 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:
- #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)
- figure out how do we cache/store result of
- 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
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>
).