Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Parse User object ACL

I'm new to parse, and have a question about the security of data in the parse User "table". I want to store additional data along with the user data. For example, phone number. But by default parse sets the user table to have read access for anyone. So if anyone just hits my parse api, they will be able to get a list of all users and their phone numbers. Obviously this isn't very secure. So should I set the user objects so they can't be read by anyone? Or should I store my details in a different table? Related, I also think it is strange for anyone to just be able to basically dump all my users default columns as well. Right now anyone with my API key can get all users and their email addresses. Am I missing something here about how insecure this is?

like image 683
TehOne Avatar asked Jan 17 '15 00:01

TehOne


2 Answers

Your concerns are quite valid. The default permissions for the Parse database are configured for easy development, so without further configuration its almost trivial for anyone to dump of all of your users. It is unfortunate that real security requires fairly significant effort when different defaults would have immediately made many applications more secure.

See this blog post for an example of how easy a user dump can be: https://www.webniraj.com/2013/08/01/using-the-parse-javascript-sdk-be-careful/

The per-object ACLs cannot provide access which has been denied by the class level permissions, so even if you don't want any publicly accessible user data, the public class level permissions for the Parse User class need to be configured in a way that allows the SDKs to interact with them:

  • Public “Get" is required for the client to be able to refresh the current user.
  • Public “Create” is required just to be able to sign up a user.
  • Public “Update” is required to be able to set the username and password.

These public permissions are then restricted further with the user ACL. The built-in User class is assigned a default ACL with public read, and private readwrite (for the specific user). I have not needed a public Read read for users, so in an afterSave Cloud Code hook, I changed the ACL to private readwrite. I did not actually even want private write access since I was going to use Cloud Code for user updates, but the ACL always returned to private readwrite.

I have not needed the ability to search for other users, so I disabled public “Find” which is the quick fix to prevent all of your user info from being dumped. Although less risky, and requiring the specific object id, the public "Get" could still be abused which is why I removed public read from the user ACL.

UPDATE:

Configuring the Class Level Permissions (CLPs) to publicly allow operations do not necessarily mean any data is publicly accessible. These CLPs specify what operations can be run on each class of the database from any client SDK (which is what they mean by “public” — using the "private” master key can still override everything). Then, ACLs on each object specify which users/roles are allowed to read and write that object. I’d highly recommend reading their 5-part blog post on security to gain an understanding of the interactions between the CLPs, and the object level ACLs: Parse Blog: Security

CLPs allow you to lock down client access to entire classes in the database. For example, I have a class used only by cloud code, so I have disabled all CLPs (preventing any client SDK from reading or writing these objects), and then the cloud code uses the master key to override the CLP for use on the server. I also have client-facing, but objects private to the user. These have public Get and Find CLPs, but are secured to the user with a private read-write ACL for only that user.

Parse also added “pointer permission” recently, which look helpful in restricting access to the “owner” of each object, but I have not personally used these: Parse Pointer Permissions

like image 147
gyratory circus Avatar answered Nov 20 '22 22:11

gyratory circus


It took me some time to wrap my head around this. For starters, you're going to want to disable new class creation, and then set the ACL on a per-class basis to (at most) be read only. You may also want to turn off read as well.

See https://parse.com/docs/data#security-classes

Then you need to set up some Roles and Users and set ACLs appropriately. You can't really setup ACLs / Roles / Users effectively through the data browser, but need to do this programmatically. I've been using the REST API and some curl snippets to experiment.

See https://parse.com/docs/rest#roles

like image 2
bmann Avatar answered Nov 20 '22 20:11

bmann