*** 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. -- Mailing list: https://launchpad.net/~mugle-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~mugle-dev More help : https://help.launchpad.net/ListHelp
