4

The scenario is as follows:

  1. 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.
  2. Each Group has one or more Admin Users.
  3. Multiple Admin Users from different Groups can be logged in at a time.

Consider the following use case:

  1. An Admin User logs into the web interface and chooses to see a list of Users in their Group.
  2. The Admin User selects a User to edit (e.g. change privileges).
  3. 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.
  4. The Admin User enters a new privilege in the form and submits the form.
  5. The web application updates the normal User's privileges in the database.
  6. 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:

  1. 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.
  2. 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.

user3337410
  • 103
  • 1
  • 7

2 Answers2

18

I think you're working on the wrong end. The server simply needs to check if the admin is authorized to edit the user right before the update. Whether or not the admin has altered the form is irrelevant and cannot really be checked, anyway. The point is that you only accept changes if the user is authorized to do them – just like everywhere else in your application.

Trying to protect the parameters is missing the point. It's also very difficult and will lead to all kinds of problems. For example, let's say an admin of group Red starts to edit user A who is indeed a member of this group at this point in time. The admin doesn't touch the form at all, but he does wait. In the meantime, user A has switched to group Blue, so the admin shouldn't be able to edit this user. However, you would probably let them do it based on the obvervation that the form hasn't been altered.

Fleche
  • 4,024
  • 1
  • 17
  • 20
  • 5
    "Never trust the user's input" applies here. The server must validate that each attempt is actually allowed by the business logic. A browser can be easily manipulated even by the fairly uninitiated (consider the successful JavaScript like-jacking that goes on over Facebook). – phyrfox Jun 17 '14 at 04:26
  • I didn't want to trust the user's input, hence the suggestion of the checksum but I guess that checksum then forms part of the user input. I didn't think about the time-lapse scenario Fleche mentioned so thanks for that. Auditing the DB update right before it occurs is probably the best option. – user3337410 Jun 17 '14 at 08:10
  • 3
    Just to clarify: Your suggestion is technically possible and not inherently wrong. For example, you could use a MAC (message authentication code) to prevent users from tampering with pre-defined parameters. However, this is five times as much complexity and only half as much security compared to a simple authorization check. So it's simply not worth it. – Fleche Jun 17 '14 at 09:22
0

Agree with Fleche, doing security through obscurity is never a good idea. Simply ensure that when an user is doing a particular action, that he/she is allowed to do that action on the requested resources.

This way, a malicious admin can try all he wants, he can only alter data on the team he's allowed to.

ndrix
  • 3,206
  • 13
  • 17