mugle-dev team mailing list archive

[Prageeth Silva <779015@xxxxxxxxxxxxxxxxxx>]

*** This bug is a security vulnerability ***

Private security bug reported:

As discussed at the last meeting, the primary key is set in the wrapper
class when casting from DataClass to ClientClass (wrapper class). This
was mainly because we needed to send the key back via a service to do
updates and similar operations.

However, after brain storming about this more, I can see that this can
have security issues. What if the client manually edit the primary key
(basically a long) and that new primary key actually mapped to another
user in the database. This means that the client would be able to change
data of other users. One may say, we can simply check on the server
whether this user is the actual user that's logged in. This would also
mean that a user is limited to changing only his profile and this could
be a problem for admins.

I still can think of a work around by simply using the UserLevels (that
was also my initial plan). But now if we consider any other model class
other than the user; e.g. UGP will contain a list of games (game keys
rather). And if the client wants to update a single game in the list by
passing down the key of that particular game, we SHOULD allow that. But
what stops the client from changing the UGP's list of games and
performing the same operation?

I can't think of a work around for this scenario, and I'm wondering if
this will be an issue or not?

** Affects: mugle
     Importance: Medium
         Status: New

-- 
You received this bug notification because you are a member of MUGLE
Developers, which is a direct subscriber.
https://bugs.launchpad.net/bugs/779015

Title:
  Wrapper class containing PrimaryKey

Status in Melbourne University Game-based Learning Environment:
  New

Bug description:
  As discussed at the last meeting, the primary key is set in the
  wrapper class when casting from DataClass to ClientClass (wrapper
  class). This was mainly because we needed to send the key back via a
  service to do updates and similar operations.

  However, after brain storming about this more, I can see that this can
  have security issues. What if the client manually edit the primary key
  (basically a long) and that new primary key actually mapped to another
  user in the database. This means that the client would be able to
  change data of other users. One may say, we can simply check on the
  server whether this user is the actual user that's logged in. This
  would also mean that a user is limited to changing only his profile
  and this could be a problem for admins.

  I still can think of a work around by simply using the UserLevels
  (that was also my initial plan). But now if we consider any other
  model class other than the user; e.g. UGP will contain a list of games
  (game keys rather). And if the client wants to update a single game in
  the list by passing down the key of that particular game, we SHOULD
  allow that. But what stops the client from changing the UGP's list of
  games and performing the same operation?

  I can't think of a work around for this scenario, and I'm wondering if
  this will be an issue or not?