Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security considerations for status codes #311

Open
csarven opened this issue Sep 17, 2021 · 5 comments
Open

Security considerations for status codes #311

csarven opened this issue Sep 17, 2021 · 5 comments
Assignees
Labels
doc: Protocol status: Nominated An issue that has been nominated for the next monthly milestone topic: resource access

Comments

@csarven
Copy link
Member

csarven commented Sep 17, 2021

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
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.

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 #14 (comment) 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.

@csarven csarven added doc: Protocol topic: resource access status: Nominated An issue that has been nominated for the next monthly milestone labels Sep 17, 2021
@csarven csarven added this to the ~First Public Working Draft milestone Sep 17, 2021
@kjetilk
Copy link
Member

kjetilk commented Sep 17, 2021

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
Copy link
Contributor

timbl commented Sep 21, 2021

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
Copy link
Contributor

timbl commented Sep 21, 2021

Is the proposal "Add requirement for Read permissions as well as Write for create and update operations"?

@timbl
Copy link
Contributor

timbl commented Sep 21, 2021

that would be a big incompatible change.

@csarven
Copy link
Member Author

csarven commented Sep 22, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc: Protocol status: Nominated An issue that has been nominated for the next monthly milestone topic: resource access
Projects
None yet
Development

No branches or pull requests

3 participants