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
JSON Patch Operation Read Permission Issue #2986
Comments
The danger in derring inline checks is that an attacker can overwrite the value of a field in a transaction. The check would have failed but because it was deferred to after their write, it now succeeds. For example. Imagine I have a user record with a field called role. The attacker's role is READ_ONLY. They can create a transaction which overwrites the role to WRITE and then perform another operation that depends on that role. Because all checks are deferred until the end, they now can perform actions with the WRITE role. |
Is there any way to fix this scenario then? I see that actually the checks were already run once during the initial pass, so even with the pull request if it did the remove authorBook operation first instead of add the request would fail as expected. If I deferred the check until the end of each post process relationship action instead of until the transaction commit would that work? Or is there some other way to handle this? |
Encountering an issue where running a transaction with 2 operations fails with a read permission denied error which if split into 2 separate transactions succeeds.
Expected Behavior
There shouldn't be a difference in outcome if the 2 separate operations in 2 separate transactions succeeds but the same 2 operations in a single transaction fails.
Current Behavior
This is happening partially because relationships are updated in a separate step.
I have a sample project where I have defined 3 models.
where AuthorBook is an entity and has a one to one relationship with Author and Book.
Author has a read permission that allows read if the user has access to Book. (The sample hardcodes this to allow access if the Book has id 1 or 2)
After the setup the state looks like this
The operations executed essentially adds AuthorBook(a1,b2) to Author and remove AuthorBook(a1,b1). When executing the transaction the failure occurs when the post processing of the relationships are being performed when Author needs to be read to apply the relationships.
The state of Author at the point of time the expression is evaluated is
This is because AuthorBook(a1,b1) was already removed. In the prior step when AuthorBook(a1,b2) was to be set on Author what was set was AuthorBook(a1,null) because it was split into the 2 phases.
Possible Solution
I don't really know enough of how the permission evaluation works but if all inline checks are deferred, similarly to what's happening for newly created resources, when performing
postProcessRelationships
then it should work. I don't know if this is a proper design or will break anything else though.Steps to Reproduce (for bugs)
I have committed a project at https://github.com/justin-tay/elide-spring-boot-example/tree/permission-issue_elide-7.x which demonstrates the issue. The queries are in the README.md but I have reproduced them below.
Setup
Operation with issue
The text was updated successfully, but these errors were encountered: