mugle-dev team mailing list archive

[Scott Ritchie <s.ritchie73@xxxxxxxxx>]

I hadnt thought that far ahead, so wasnt thinking it was *that* serious of a
security bug.
What i meant was that the way we're developing the UI, when we write/update
objects we go through Prageeth's security wrapper layer.  However you can
still access the services layer from the client side, bypassing Prageeth's
wrapper layer.   So my suggestion was to make all those services classes in
shared.model.services protected, rather than public - that way only the
wrapper can access them.

On Sat, May 21, 2011 at 10:01 AM, Matt Giuca
<786016@xxxxxxxxxxxxxxxxxx>wrote:

> 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 direct subscriber
> of the bug.
> 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
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/mugle/+bug/786016/+subscribe
>

-- 
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