mugle-dev team mailing list archive

[Matt Giuca <786016@xxxxxxxxxxxxxxxxxx>]

OK. Thanks for filing this bug as a security vulnerability (that's good;
it makes Launchpad make the bug private by default), but why did you
change it to public? I'm setting it back to private -- it's best not to
disclose these problems. A private bug can be seen by anybody on the
team, but nobody else, which should generally be the case for security
vulnerabilities. Also please refrain from discussing this issue on the
mailing list (which is public).

Now, what do you mean by "should be changed to Protected"? I'm not sure
what that is. How does it help? I don't really see a good solution to
this problem without having a separate domain for each game.

The crux of the problem is this: we have (hopefully) coded the internal
API to have proper server-side security, which means each user can do
only things that that user has permission to do. Admins can do
everything, dev teams can modify their own games, individual users can
only modify their own UGPs, etc. That's fine.

The problem is that when we run a game, the game code has been written
by developer A, but is running in user B's account. That means that
developer A could upload some code that can take any action on behalf of
user B, including modifying user B's UGP for other games, and, if user B
is a developer, having complete control over user B's account.

An even worse side-effect of this is it allows a particularly malicious
developer to hide his tracks, by using another developer's account.
Since it would look bad for developer A if someone found out that he had
malicious code that takes over another user's account, developer A could
take over developer B's account and then upload his malicious code as a
game owned by developer B, then delete the malicious code off of his own
game. Then, developer B's game will be used to attack other users,
without developer B's knowledge. Developer A is in control, but the
offending code can't be traced back to developer A.

This could be fixed by having separate subdomains for each game, but
that would complicate things a lot.

A possible easy fix is to have the internal APIs check the HTTP Referer
header. This header tells the server exactly which page sent the Ajax
request (and cannot be forged by the client -- see
http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method), and
refuse to work if the referer is NOT from a URL we are in control of.
That could resolve it nicely, and wouldn't be hard to implement.

** Changed in: mugle
   Importance: Medium => High

** Changed in: mugle
       Status: New => Triaged

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

Title:
  Direct Access to Services from client side

Status in Melbourne University Game-based Learning Environment:
  Triaged

Bug description:
  While Prageeth has coded the casting of shared objects to datastore
  objects to have security checks, these can be bypassed by calling the
  shared services directly.  The type of these classes should be changed
  to Protected if possible to avoid this