Conversation
UserService.updateUser deserialized the caller's raw request body directly onto the User entity with no field restriction, then persisted it via updateByPrimaryKeySelective. The global tenant SQL interceptor scopes which row an UPDATE can reach (by the caller's own tenant), but not what the SET clause writes, so a caller could set tenantId to 0 on a user they own (e.g. a sub-user created via the ordinary /user/add flow). tenantId 0 is treated by the tenant interceptor as unrestricted super-admin, no filter applied, on every later request made with that account's token: full read/ write/delete access to every other tenant's data on the instance. Strip tenantId from the entity before the update so it can never be set through this endpoint.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #165.
UserService.updateUserdeserialized the caller's raw request body directly onto theUserentity with no field restriction, then persisted it viaupdateByPrimaryKeySelective. The global tenant SQL interceptor scopes which row an UPDATE can reach (by the caller's own tenant), but not what the SET clause writes, so a caller could settenantIdto0on a user they own (e.g. a sub-user created via the ordinary/user/addflow).tenantId 0is treated by the tenant interceptor as unrestricted super-admin, no filter applied, on every later request made with that account's token: full read/write/delete access to every other tenant's data on the instance. This stripstenantIdfrom the entity before the update so it can never be set through this endpoint.