Security/ACLs in Coronium

Third Party Coronium
#1

Like so many others I’m looking for a Parse replacement, and wow, I was blown away by how extensive and feature complete Coronium is.

However one Parse feature that I can’t find is security rules for data. Parse provides class- and row-level ACLs that allow you to restrict access to the logged in user. This is important because you want your game client to only be able to read/modify data that’s available to that user. (http://blog.parse.com/learn/engineering/parse-security-i-are-you-the-key-master/)

Coronium has Parse-style Users (check!) and Parse-style Data Objects (check!) but I can’t find anything in the docs that links them together, particularly from a security standpoint. What is the recommend way to limit the game client’s access to server data? Maybe I’m missing something obvious. Thanks!

#2

Hi,

This is something that will be integrated a little more in the next version, but generally, you can handle this on your end via server code.

An ACL entry is really just another Object in Parse, so the same can be done via Coronium.

A (very general) approach might be:

  • Create an ACL collection and assign “roles”, so an “admin” record, “manager” record, etc. and whatever additional meta you want to attach to the record.
  • Use Cloud code to “route” your data (coronium:run). Check the ACL record against Users ACL Object ID assignments. You can use are array to store multiple ACL ids on your User record.
  • Return proper response depending on conditional results.

This is what Parse does at a very simplified level. Most of it is behind the scenes, but with Coronium you get the pride of building your own system. :slight_smile:

Additionally, I think it’s important to note that ACL is one approach. Using Cloud Lua and some database work, you can implement a system as simple or as complicated as you’d like. You could skip the ACL approach all together and use an ID as a data definer.

Be creative, that’s the nice about Coronium. It’s a Cloud, but you don’t have any reason to have to have it act like every other system. Make it work for you. The basic tools are there, but every built it module can be recreated and repurposed through Cloud Lua as well.

There is also a member here on the forums (Nick) who is migrating a larger Parse project to Coronium, who may be able to provide some tips. I believe his company is rolling their own ACL. Hope that helps.

Cheers.

#3

Thanks! That’s extremely helpful. 

#4

Following up here, I’ve begun implementing a system for storing saved games using coronium. However I’ve hit what I think is a security issue. The client side Data Objects functionality seems to allow full read+write access to any collection in the _objects table, meaning if a malicious user can guess that I have a “Players” collection, they could delete everything in the collection by doing this:

mc:getObjects(“Players”)

…loop through results…

mc:deleteObject(“Players”, result.objectId)

Even over SSL it would not be impossible to get the API key and URL structure by looking at their outbound network traffic. I’m not sure how you’d do this on mobile (Android Monitor?) but it’s possible using Chrome dev tools so I’m guessing it’s possible to intercept it before it’s encrypted. If not, they could get the URL structure by looking at the Coronium source, and the API key by poking around in the compiled APK, which preserves strings in cleartext. But in general it’s not safe to assume anything in the client can be kept secret from a malicious user.

So the only workaround I can think of is to name my collections un-guessable things, like long random hashes, and then only my cloud code will know the names of the tables. In order to access them from the client, I’d call cloud code methods like mc:run(“updatePlayer”, newData) and then updatePlayer.lua on the server would user the mongo package to make the change. 

#5

Hi,

I can see your point. This is why the User class does not allow this.

I think all deletion operations should be done in cloud code, and will be moving this one as well.

Thanks for sharing.

Cheers.

#6

Hi,

This is something that will be integrated a little more in the next version, but generally, you can handle this on your end via server code.

An ACL entry is really just another Object in Parse, so the same can be done via Coronium.

A (very general) approach might be:

  • Create an ACL collection and assign “roles”, so an “admin” record, “manager” record, etc. and whatever additional meta you want to attach to the record.
  • Use Cloud code to “route” your data (coronium:run). Check the ACL record against Users ACL Object ID assignments. You can use are array to store multiple ACL ids on your User record.
  • Return proper response depending on conditional results.

This is what Parse does at a very simplified level. Most of it is behind the scenes, but with Coronium you get the pride of building your own system. :slight_smile:

Additionally, I think it’s important to note that ACL is one approach. Using Cloud Lua and some database work, you can implement a system as simple or as complicated as you’d like. You could skip the ACL approach all together and use an ID as a data definer.

Be creative, that’s the nice about Coronium. It’s a Cloud, but you don’t have any reason to have to have it act like every other system. Make it work for you. The basic tools are there, but every built it module can be recreated and repurposed through Cloud Lua as well.

There is also a member here on the forums (Nick) who is migrating a larger Parse project to Coronium, who may be able to provide some tips. I believe his company is rolling their own ACL. Hope that helps.

Cheers.

#7

Thanks! That’s extremely helpful. 

#8

Following up here, I’ve begun implementing a system for storing saved games using coronium. However I’ve hit what I think is a security issue. The client side Data Objects functionality seems to allow full read+write access to any collection in the _objects table, meaning if a malicious user can guess that I have a “Players” collection, they could delete everything in the collection by doing this:

mc:getObjects(“Players”)

…loop through results…

mc:deleteObject(“Players”, result.objectId)

Even over SSL it would not be impossible to get the API key and URL structure by looking at their outbound network traffic. I’m not sure how you’d do this on mobile (Android Monitor?) but it’s possible using Chrome dev tools so I’m guessing it’s possible to intercept it before it’s encrypted. If not, they could get the URL structure by looking at the Coronium source, and the API key by poking around in the compiled APK, which preserves strings in cleartext. But in general it’s not safe to assume anything in the client can be kept secret from a malicious user.

So the only workaround I can think of is to name my collections un-guessable things, like long random hashes, and then only my cloud code will know the names of the tables. In order to access them from the client, I’d call cloud code methods like mc:run(“updatePlayer”, newData) and then updatePlayer.lua on the server would user the mongo package to make the change. 

#9

Hi,

I can see your point. This is why the User class does not allow this.

I think all deletion operations should be done in cloud code, and will be moving this one as well.

Thanks for sharing.

Cheers.