The scenario is as follows:
- An application has a web interface through which data can be configured. The data to consider for this question is Users with a many-to-many relationship with Groups.
- Each Group has one or more Admin Users.
- Multiple Admin Users from different Groups can be logged in at a time.
Consider the following use case:
- An Admin User logs into the web interface and chooses to see a list of Users in their Group.
- The Admin User selects a User to edit (e.g. change privileges).
- The Admin User is redirected to an edit page for a single User with the normal User's ID in a hidden field in the edit page.
- The Admin User enters a new privilege in the form and submits the form.
- The web application updates the normal User's privileges in the database.
- This aspect of the web application does not require performance optimisations, operations on the order of a few seconds is acceptable.
It's naive to believe the normal User's ID can't be edited on the client side thereby allowing the Red Admin User of Red Group to change the privileges of a normal User of Blue Group (of which the Red Admin User is NOT a member).
What can be done on the server side to protect the integrity of the ID of the normal User being edited?
For the purposes of this question, assume that the Red Admin User has been correctly authenticated and is allowed to view the edit page of a normal User of the Red Group. I'm concerned here with the Red Admin User maliciously changing the hidden User ID of a normal User of the Red Group to change the properties of Users of other Groups.
Specifically, this system is developed using Java EE running on a Glassfish server.
I've considered the following solutions:
- Embed a cryptographic checksum incorporating the User ID as a hidden field in the edit form. An MD5 hash or similar would be inappropriate as the Red Admin User would just need to calculate the new hash. The hash would need to be derived from some server-side secret. Obviously the secret would need to be unpredictable and protected.
- Currently the system uses a stateless session bean to carry the ID of the normal User to be edited from the list of Red Group Users to the User edit page. I could change the session bean to be a stateful bean would would maintain the User ID to be edited within the server but I'm considering other alternatives.
What other options should I consider to combat this particular threat? Subjects such as user authentication and secure transmission are outside the scope of this question.