search

EOSIO / manifest-spec

A specification detailing how EOSIO-enabled applications comply with the application manifest requirements of EOSIO-compatible user agents
MIT License
9 stars 5 forks source link

Consider simpler support for apps that control all of their subdomains #10

Open brandonfancher opened 5 years ago

brandonfancher commented 5 years ago

The current manifest spec model treats subdomains as separate apps. This is a feature--domain owners may want to run multiple apps from their domain, or they may want to lease subdomains to others to control.

This presents quite the overhead for applications that utilize many subdomains and control all of their subdomains. They must serve a custom chain-manifests.json from the root of each subdomain...even if they want all of those subdomains to appear as the same app. Furthermore, serving static files like this from each subdomain often requires extra setup, like custom modifications to webpack, etc. This can hurt adoption of the standard.

For discussion, here's an improvement idea for scrutiny:

Premise: A request (e.g., a transaction) is proposed from, say, https://gazelle.eos.io (i.e., declaredDomain is https://gazelle.eos.io).

Current Behavior: Conforming authenticators would attempt to fetch https://gazelle.eos.io/chain-manifests.json. If it's not present, the authenticator would throw and error and not allow the request.

Proposed Behavior: Conforming authenticators would attempt to fetch https://gazelle.eos.io/chain-manifests.json. If it's not present, the authenticator would attempt to fetch https://eos.io/chain-manifests.json. If it is present, the authenticator would verify that the manifest domains therein contain a wildcard (*) as the subdomain (i.e., *.eos.io). If there is a wildcard, that chain-manifests.json would be accepted and remaining checks would be done. If there is no wildcard, the manifest would be rejected.

This allows a domain to declare that they own and control all subdomains, but still gives them the flexibility to customize manifests for any subdomain they wish.

Does the security model hold?

brandonfancher commented 5 years ago

@bhazzard, @TaraTritt, @jeffreyssmith2nd, @Todd-Bowden, @tbfleming:

Would you guys mind reviewing the thoughts above to validate the approach from usability and security standpoints?

tbfleming commented 5 years ago

Explorers that watch add.manifest would also need to understand the wildcard in the domain field.

brandonfancher commented 5 years ago

True. I'm not aware of any explorers in existence yet. So now's a good time to be making these kinds of changes.

TaraTritt commented 5 years ago

I think this is a tradeoff in security for usability. I think allowing a wildcard in the manifests domain would open up an attack vector due to common subdomain takeovers, but i do think that it provides an easier onboarding experience to meeting the specification. Haven't fully thought out the repercussions or feasibility of this yet, but is it possible for the manifests domain field to allow an array of domains, which could include subdomains? It would still attempt to find the chain-manifests.json in the manner that you discussed, but validate against the domain (maybe update the name to domains) array to confirm that it contains the subdomain url where the request originally came from. This also might decrease the burden on app developers.