Open csarven opened 3 years ago
kjetilk
commented
3 years ago That's a good formulation of the problem, @csarven !
I am certainly divided as to how we should approach this, so I'll just leave the floor open. I would only like to note that if we use the same status codes for create and update operations, I believe it would indeed be a violation of RFC7231.
timbl
commented
3 years ago The issue title needs to be a crisp summary of the problem. "Security considerations for status codes" invites no end of philosophical ramblings in an area already prone to too much of that.
timbl
commented
3 years ago Is the proposal "Add requirement for Read permissions as well as Write for create and update operations"?
timbl
commented
3 years ago that would be a big incompatible change.
csarven
commented
3 years ago No, I want to clarify protocol's position and checking to make sure there no oversights or misunderstandings of the specs.
As things stand, a successful response to create and update operations "reveal both the past and current state of a target resource."
It depends on the whether that's an issue and if so stating its severity.
Disclosing the existence of a resource is less severe than reading the resource.
The question was (and I'm sure it can be phrased better):
Do operations to create and update resources encompass read permissions on the target resource within the framework of HTTP?
I want to include a statement in Security Considerations one way or another.
As HTTP response status codes indicate the result of a request, there are security considerations to take into account depending on the state of the target resource of an HTTP request.
Depending on the request semantics, both success and error responses can reveal both the past and current state of a target resource.
Example:
The 201 status code in the response of a PUT request indicates that the target resource did not have a current representation and that one was created successfully, and 200 or 204 indicates that the target did have a representation and that the target was modified ( https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4 ). There are other 2xx codes that can occur but that's irrelevant for this discussion.
View the RFC 7231 requirement for successful responses to PUT
Access control mechanisms typically make the distinction between permissions to view the state of a resource from permissions to change the state of a resource. Here, "change" may create or update the target resource of an HTTP request.
This brings us to the following question:
Do operations to create and update resources encompass read permissions on the target resource within the framework of HTTP?
For instance, a client may have write-only access on the target resource, and while it would be authorized to change its state, it would not be authorized to know about its state. Whether the class of write operations split into specific operations is irrelevant here.
Noting that the use cases to write-only are rare, so in practice both read and write would be given to allow a write operation. However, this is orthogonal to how authorization rules could be set.
One way to implement an authorization system that makes a clear distinction between read and write operations that also conforms to RFC 7231 would be: Only when a client has both read and write permissions, a successful response to a PUT request can be 201, 200 or 204. A less "strict" implementation however may reveal the same status codes when client has only write permission. See for example the table on PUT in https://github.com/solid/specification/issues/14#issuecomment-683480525 that currently gives importance to using 7231's status codes, i.e., read permission on target resource is not required to reveal its past state.
Another approach here is to use the same status code whether the resource state is created or replaced. However, that raises the question whether such implementation strictly conforms to RFC 7231 or if there is some leniency that can be worked out, or if some degree of wilful violation is necessary for the Solid Protocol.
There are others examples - like with POST, PATCH or append-only operation, or even when specific headers like If-None-Match are in play - that can be classified under the same security considerations but I'd like to keep it simple for the moment by focusing on what the status codes reveal. But feel free to raise them in the comments in any case.