mugle-dev team mailing list archive

[Matt Giuca <786070@xxxxxxxxxxxxxxxxxx>]

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

Private security bug reported:

The games hosted on the MUGLE platform currently have access to the
internal API, which means they can perform commands on behalf of the
logged-in user who is playing the game. Note that we require application
developers to obtain a game key to use the developer API, but we don't
(and can't) require a similar mechanism for our own internal API.

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.

** Affects: mugle
     Importance: High
     Assignee: Matt Giuca (mgiuca)
         Status: Triaged


** Tags: security

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

Title:
  Games have access to the internal API

Status in Melbourne University Game-based Learning Environment:
  Triaged

Bug description:
  The games hosted on the MUGLE platform currently have access to the
  internal API, which means they can perform commands on behalf of the
  logged-in user who is playing the game. Note that we require
  application developers to obtain a game key to use the developer API,
  but we don't (and can't) require a similar mechanism for our own
  internal API.

  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.