Trust between owners on same origin with multiple storages #290
Conversation
kjetilk
left a comment
kjetilk
left a comment
There was a problem hiding this comment.
This, I think is a sufficient explanation. In a subsequent best practice document, we should also say that this means that unless you know what you're doing (like making a server for your family), you should ensure that different users have different origins.
kjetilk
left a comment
kjetilk
left a comment
There was a problem hiding this comment.
Great, I think this strengthens it even further.
protocol.html
Outdated
|
|
||
| <p>Servers <a href="#cors-server">disable all cross-origin protections</a> in browsers because resource access is governed explicitly by the <a href="#authorization">Authorization</a> component. As such, servers cannot rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource. In particular, servers are strongly encouraged to ignore HTTP cookies from untrusted origins. Additional security measures can be taken to prevent metadata in error responses from leaking. For instance, a malicious application could probe multiple servers to check whether the response status code is <code>401</code> or <code>403</code>, or could try to access an error page from an intranet server within the user agent’s private network to extract company names or other data. To mitigate this, when a request from an untrusted <code>Origin</code> arrives, the server may want to set the status code of error responses to <code>404</code> and/or anonymize or censor their contents.</p> | ||
|
|
||
| <p>Servers are discouraged from implementing <a href="#storage">multiple storages on the same-origin with untrusted owners</a> because Web apps running in one storage will have the same rights as Web apps running in the other.</p> |
There was a problem hiding this comment.
Because Web apps running in one storage will have the same rights as Web apps running in the other
I think adding a bit more detail here on the context (e.g. browser-based apps relying on same origin policy) and the attack vectors would be helpful. Understanding the risk better should make it easier for the reader to understand why they are being discouraged from hosting multiple storages in same origin.
There was a problem hiding this comment.
To continue @justinwb's comment, it is important to be clear about the assumptions that underlie this statement. If, for instance, CORS is used as the basis of identifying applications, which in turn is used for access control, then yes, this would be an important point to make.
If, however, applications are identified through another mechanism, I struggle to understand why this statement would be needed.
I would also mention that CORS-based restrictions are only going to be relevant for certain browser-based use cases. It is entirely irrelevant for non-browser contexts and even for browser contexts, there are fairly easy ways to circumvent same-origin restrictions (i.e. adding a proxy service)
There was a problem hiding this comment.
👍 both previous comments
because Web apps running in one storage
I also find word running in this statement possibly leading to some confusion. While application source can be published to solid storage, that application runs in a web browser on someone's device.
Applications running on remote server (aka 'server side') are perfectly fine, in some ways can be even better, solid applications. Those run on the server at certain origin but can not be deployed to a solid storage.
kjetilk
added
the
status: Nominated
csarven
force-pushed
the
editorial/trust-between-owners-same-origin-multiple-storages
branch
from
f0f305d to
cdebf01
Compare
csarven
deleted the
editorial/trust-between-owners-same-origin-multiple-storages
branch
|
As per CG's review and agreement https://github.com/solid/specification/blob/main/meetings/2022-11-30.md#trust-between-owners-on-same-origin-with-multiple-storages : This PR introduced advisory content under Security Considerations. Concerns were raised in the comments of this PR and elsewhere. The CG agreed to leave out this advisory (in 2022-11-30 meeting). There was no objection to removing the Note and some approval to remove it. This PR however originally only made an editorial change to the Note (clarifying "on the same-origin" as per agreement in https://github.com/solid/specification/blob/main/meetings/2021-07-27.md#minutes based on #267 (comment) ) so the action was limited to removing the advisory under Security Considerations. On second review, I took it on myself to remove the Note as well - given consent - based on the grounds that the advisory is too vague to be implementable by a server and/or actionable by owners involved at this time. |
Closes #267