Parse-server: Does Parse-Server verify if the client is legitimate for every request?

[noder199]

Does parse-server/Parse-SDK-iOS-OSX implement any methods of verifying whether the client is in fact legitimate? This would be for preventing mass account creation and similar issues. Doing something like a checksum would be ideal (Take the account name, API version, and a known secret and hash them together so the server can detect a fake client.).

This post on reddit describes what I mean: https://www.reddit.com/r/iOSProgramming/comments/50lub5/what_stops_a_user_from_spamming_the_creation_of/

I would consider this issue a feature-request if something similar to a checksum isn't already implemented.

[flovilmart]

As the SDK's are opensource too, A checksum would be ineffective. All those protections are usually implemented on a need to know basis.

Imagine we add the suggested checksum, and update all SDK's what prevent a malocious user to craft a nodejs app with the new SDK's and blast those same requests to your server? Nothing.

[noder199]

@flovilmart Even when using a secret key?

What do you suggest is an alternative solution? Is there anything you do for your own applications to prevent a user from just spamming requests to your app at any time without blocking out users with tools like rate limiting?

[flovilmart]

Secret key on the client? doesn't seem that secret. Some companies use rate limiting, machine learning, delays upon signup/login etc... But I don't think that fits within the scope of that project.

[noder199]

Yes but it still forces the user to disassemble the client, it acts as a layer of defence - I guess as all things in security.

Rate limiting can cause entire schools or businesses to be black listed in certain cases.

Certificate pinning isanother possibility, although it is tedious as I would have to bundle the file every time it is renewed (yearly).

I would be curious if you or anyone else has seen this sort of annoying behaviour in their app, and what they did to stop it. If it is a one off occurrence using a single ip you can just block the user but that isn't always the case.

[noder199]

Also worth mentioning that cloud providers like GAE don't provide features like dynamic ip restrictions.

[flovilmart]

Yes but it still forces the user to disassemble the client, it acts as a layer of defence

Disassembling JS very complicated I guess... Finding strings in a binary is as much complicated. Given that the applicationId has to be in the client too, the attacker need it to make 'successful' requests to your device.

I am not saying that it is impossible I'm just saying it's completely out of scope for that project. IF you want to achieve security, there are many things you can do, all of them are debatable, the iOS SDK is open source, you can very well swap the way API calls are made from your own fork etc...

Do you ask express.js to do rate limiting/certificate pinning/any other security? do you ask mongoose to do rate limiting? No, this is a deployment issue, and if GAE don't provide a feature you need, you can deploy it anywhere including a computer in your basement, with as many firewalls as you want.

You can put a cloud flare in front, you can do all sorts of things to protect the application layer, and most of the times, there will be a work around, a zero day in a package on your system.

If someone wants to makes your life hell, he'll be able to do it. But that's not our responsibility to provide those solutions.

Your question is better suited to stack exchange/server fault/stackoverflow as it applies to any kind of deployed server opened in the internet.

[noder199]

Do you ask express.js to do rate limiting/certificate pinning/any other security? do you ask mongoose to do rate limiting? No

Well no, express does not promise to be anywhere near as ambitious or as practical as parse-server is, I mean I don't even know how you could compare the two. Express is for building a backend, parse-server IS a backend.

If someone wants to makes your life hell, he'll be able to do it. But that's not our responsibility to provide those solutions.

Well that's stupid, I mean if I have some free time I'll take a look at your application with charles and see whether a repeated request every x number of seconds is detected by your service. I bet it isn't, are you okay with that? You do realize how easy that is to abuse..

Who are you to state whether it is the responsibility of myself or of the repository holders? Did the original hosted parse not have any of these mehanisms in place? I doubt it, so an effort is worth being made. I do not see how such a tirade could be made against a reasonable request for a feature, some security mechanisms are definitely handled by the load balancer, others can be on the application .

Your question is better suited to stack exchange/server fault/stackoverflow as it applies to any kind of deployed server opened in the internet.

Well, why don't you try asking for a feature request or for advice on stack, the question won't be open for long. Cmon.

[flovilmart]

Who are you to state whether it is the responsibility of myself or of the repository holders

I'm a maintainer, I state what I believe is best for the project.

I bet it isn't, are you okay with that? You do realize how easy that is to abuse..

You're 100% right! Feel free to flood us with dummy requests!

Did the original hosted parse not have any of these mehanisms in place?

Yup, it was called rate limiting, and on a free plan it was 30 req/s. After that all request dropped. Making legitimate calls being dropped unless you pay the price.

Well, why don't you try asking for a feature request or for advice on stack

I don't ask for feature request, I send pull requests.

[noder199]

You are clearly ignorant of other points of view, you made a decision and won't reconsider. That is not the job of a maintainer.

The 'dummy' calls you are referring to could cause serious issues in the prospect of account creation, especially when anonymous users are enabled. You might think verification emails already solve the problem, but that isn't true for a mobile app.

Obviously if you making so many pull requests then you wouldn't waste your time arguing with a feature request. C'mon.

Anyway, it is a total waste of time to receive any open minded feedback on this, so I won't continue bulling heads.

[flovilmart]

I don't really need your insults, and you should check your tone.

However if you feel that's a critical feature that deserves to be included in the core code base, i'll gladly review and merge your PR. So far, I don't see anything constructive, nor you'be demonstrated that this particular feature request is critical to the project.

In the mean time, you should probably tone down. Insults are not really tolerated here.

[flovilmart]

@noder199 I've reported your profile as you mentioned intentionally harming our deployments and that'a not acceptable.