I would argue that there is an entire class of errors and vulnerabilities that arise from the lack of proper authentication/authorization that are not solved by solved by same-origin, and in fact might be made worse by it!
By my understanding, the cited GitHub security advisory deals with fetching a document from some location, while describing a subject whose id that does not match that location.
There is nothing inherently wrong with this! The claim you should be verifying is a different claim than the one that is actually being verified:
- Incorrect: The current document is an authentic representation of the current resource.
- Correct: The current document is authorized to make authentic statements about a given resource.
Understandably, it is easier to establish the former than the latter; we simply assume that anything can make authentic claims about itself. The descriptor document served at the URI in the id is conflated with the thing itself.
Trying to establish the latter usually goes no further than same-origin at most. If you assume that every URI on a given authority has the same controller, then this is fine. But this is a false assumption, because URI authority can be delegated at any point along the path, for example by configuring a web server to pass requests on a certain prefix to a different application entirely. /media might be served by a different application entirely than /users. This shouldn’t be a problem, but it is a problem because the real authority is never specified; the same origin assumption is used instead of establishing any real authority.
The error in logic that caused the vulnerability was conflating the two claims. Instead of passing down the document location, Mastodon passed down the id, because Mastodon assumed they would always be the same, but they are not always the same.
In fact, the related security advisory GHSA-jhrq-qvrm-qr36 demonstrates another fallacy of the “same-origin” line of thinking. The way that this security advisory is framed is actually papering over the flaws of same-origin instead of addressing the actual underlying issue. The assumptions being made by fediverse software aren’t being corrected, they’re just being augmented with other assumptions which may themselves be incorrect. The end result is a far more complicated security model built on quirks. Whenever the next vulnerability happens due to same-origin being insufficient, it will probably lead to yet another ersatz requirement being placed on what constitutes a “valid” or authentic activity, object, post, profile, key, etc.
I don’t see a good reason to continue placing such unnecessary requirements. Identity servers and keyservers shouldn’t be discarded entirely and for no good reason; this just creates unnecessary fragility where a bidirectional claim is sufficient (actor declares key as representative; key declares actor as controller). Actors and their objects shouldn’t be locked to the same domain; this unnecessarily creates barriers to real distributed systems and to cross-domain migration.
In short, “same origin” is a model that might be sufficient for centralized models of security, but it is insufficient for true decentralized security. I don’t think it’s a good idea to enshrine the assumption that a single server rules everything on that domain, or that there is only one such server possible.
Instead, we should strive to recognize not just the properties of objects, but also who is claiming these properties. Before merging graphs or datasets, we should establish that they (or their associated document) are trustworthy about the claims contained within. This is in effect what “object proofs” should be doing – signing the graph or subgraph containing only statements about a single subject.