josephguillaume
commented
1 year ago I should add that @Otto-AA noted that in addition to risk from unauthenticated users, there is a risk of privilege escalation for users with write permission on only parts of a server: https://github.com/SolidOS/solid-panes/issues/372#issuecomment-1474791492
An even stronger requirement would therefore be that a server MUST apply security-necessary constraints to any resource exposed to write and append permissions by any agent other than the owner.
This issue complements #514, which focuses on serving html rather than writing of HTML. It also follows up on an implementation specific issue raised on https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1596
The spec allows constraints to be specified (https://solidproject.org/TR/protocol#constraints-problem-details) but as far as I can tell does not currently require any constraints
At the moment the spec does not appear to prevent writing of HTML to a server by unauthenticated users in cases where public write or append permission has been granted.
Such permission is a useful part of an inbox, so it looks like this an issue for the LDN specification as well, but applies generally to writing to a server.
I believe a minimum requirement is for the spec to require that a server use constraints that by default prevent or sanitise executable code on write for unauthenticated users.
A stronger version would be that a server MUST apply security constraints to any resource exposed to write and append permissions by unauthenticated users.
Out of the box, we don't want to allow accumulation of spam documents with possible security risks, regardless of how their risk is mitigated when served or on the client side.
Depending on interpretation, this possibly also has implications for the question: "Do features in this specification enable new script execution/loading mechanisms?"
Arguably the spec does enable new mechanisms for loading scripts into a server, and therefore into a privileged context from which new attack surfaces are possible.
If this issue is already somehow covered by the spec, it would be useful for the mitigation to be summarised in this or another security question.