Parse-server: VolatileClass ignores the CLP

[pungme]

Issue Description

I'm not sure this is by design or not but we face some issues with the spammer with this exploit.

When we set the CLP for the volatileClasses (_JobStatus, _PushStatus, etc .. ), it ignores and use the default one.

Steps to reproduce

1. Set CLP for volatileClasses, in our case, we set CLP for _PushStatus to readonly and no write except masterKey.
2. try to create _PushStatus object without masterKey

Expected Results

The server should reject the request because of CLP

Actual Outcome

The server ignores the CLP and create the _PushStatus object

Environment Setup

• Server

  • parse-server version (Be specific! Don't say 'latest'.) : 2.4.1
  • Operating System: centos
  • Hardware: [FILL THIS OUT]
  • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): elastic beanstalk

• Database

  • MongoDB version: 3.2.11
  • Storage engine: WiredTiger
  • Hardware: [FILL THIS OUT]
  • Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): mLab

Remarks

• We've patched this issue on our side and will create the PR for that. Right now the other way would be checking in the beforeSave and beforeFind if you have this problem

[natanrolnik]

Hey @pungme thanks for your contribution in the PR!

I'm not sure I understand correctly what is the problem.

I think that setting CLPs for Volatile Classes should not be allowed at all - this might be a different problem by itself.

You mentioned:

Because we handle all the push notification from cloudCode and don't let client side do the push

Why would you need to change the CLP in order to access _PushStatus from Cloud Code?

[pungme]

Hi @natanrolnik thanks for a prompt response.

Maybe i didn't explain it clear enough. About your question, we don't set CLP in order to access _PushStatus, we set the CLP because want to block everyone else from create the _PushStatus object.

Right now you can create _PushStatus object right away if you you know appId and javascriptKey or clientKey (which is public because it shipped in the client) This could potentially make a spammer spam the _PushStatus class by creating a lot of objects

[flovilmart]

This is definitely an issue, those classes should be protected by the masterKey only access, not CLP's

[pungme]

Hey @flovilmart thanks for a prompt reply

Right now our interim solution is to use the CLP as you can see in the PR. Maybe we can update the PR as you suggested. So all the volatileClasses should be all masterKey only, is that correct? Right now with our test, we can create _PushStatus and _JobStatus objects without masterKey

[flovilmart]

Yep, they should be. I'm not sure why we forgot to restrict their access in Read/Write. _Session should be available to the logged in user only.

[benedickt12]

@flovilmart, @pungme

In _Session you still can write if you were logged in user, there is nothing can stop someone from creating an account then write to that collection. A better way from my opinion:

• let Parse Server creates only one Session by Device, if the Session exists for the Device override it
• Create a TTL index on MongoDB and set a column name to delete the session when it expires

The best way

• If you setup a RedisCache let Parse Server manages sessions in Redis and never write them to MongoDB then delete the Session collection.

About this issue and its PR, there is something additional you can do. Delete these collections and create them again as Capped Collection set the maximum numbers of documents in the collection to be 1000 or something suitable. This will make MongoDB replace old documents by new ones, if any new documents come after 1000, they will override the old ones.

We can also have a config attribute whenever it is turned on, prevent Parse Server from writing anything to these collections then you can easily delete them, as I honestly don't see anything useful in the information stored specially in _PushStatus, specially if you are using a custom Push Adapter like SNS or OneSignal!

But what could prevent the spammer from writing to other collections in your App anyway ?

[pungme]

Hey @benedickt12 Thanks a lot for sharing!

Your idea with Capped Collection/ RedisCache is pretty nice but there are quite a work to be done.

About the _PushStatus, we're relying on the parse-server to handle individual push notification. We only use OneSignal for the mass amount of push (most of the case, send to all)

About your question with spammer can still writing to other collections, that's true. But we locked down other collections with CLP and open up only to the one that's necessary, like _User for example. This way it will make things much more manageable and we can focus our resources to defend a certain class.

But with the current parse-server version, you can't lock _PushStatus with CLP and the default is public write (which is probably an exploit since @flovilmart pointed out those classes should be protected by masterKey only and should ignores the CLP). You can just spammed create objects or do count operation on _ParseServer or _JobStatus.

The way right now to defend if you're using current parse-server is to catch it in beforeSave / beforeFind and check for masterKey there. Or you can filter it on an nginx level, etc ..

[miguel-s]

Hey everyone!

Just wanted to chip in, as we're currently dealing with the same issue. Our temporary fix is to block access to these volatile classes (and also other classes) in the beforeFind or beforeSave hooks, just as @pungme does.

I saw there's already a pull request to fix the issue, but if there's anything I can do to help just let me know.

[benedickt12]

@pungme
How often are you getting spammed? aren't you able to identify the source/origin of the spam/attack to stop it permanently in anyway? are you running a web or mobile application?

[pungme]

Hey @benedickt12 we got every other week or something. And all ips are either tor exit node or vpn proxies. We're working with the police right now to identify the attacker.

[benedickt12]

@pungme Good luck! however if the ips are from tor or vpn it will be really hard to trace him and the police cannot do much if the attacker is not in your country, unless you are such Government entity or important company like Banks.

You should in this case better focus on improving your backend and security like you are now doing.

This is obvious if you are using open source, you are more likely to get spammed, think about it as you are running wordpress and you didn't enable CAPTCHA, you can get floud of spamming comments out of no where.

We experience such thing too and we can always deal with it.

[pungme]

Hey @benedickt12 thanks for the suggestion. We do have other evidences other than the ip address.

[benedickt12]

@pungme what kind of evidences? is it something you can catch at parse server or web server level? would be nice to share your experience so everyone here can benefit.

[pungme]

Hey @benedickt12 we can't say anything much yet since it's a part of police investigation. But we'll sure write it up and share it once it's over soon.

[flovilmart]

Thank you!
Spark by Readdle

[benedickt12]

Thanks! that will be definitely helpful for the community.