13

I'm writing a small web application as I'm learning to use the features of Parse.com.

Since application_id and javascript_key are both public (as explained in the doc), it means anyone is free to run code like illustrated in the following snippet:

function sendRequest(){

    var query = new Parse.Query(Parse.User);
    query.find({

        success: function(results) {
            console.log("Request sucessful");       
        },

        error: function(error) {
            console.log("Request error: " + error.code + " " + error.message);
        }
    });
}

setInterval(sendRequest, (1000 / hitsPerSecond));

I think it can lead to "DOS" attacks pretty easily - anyone willing to bring this app down would only need to recover the public keys and send lots of requests.

edit Accounts have a request/s limit, free plan begins at 30, but using this simple script can saturate any subscription plan.

considering this is correct - is there any good practice against this? Any pattern to apply?

Thanks in advance,

Jem
  • 6,226
  • 14
  • 56
  • 74
  • 2
    I don't know the official answer, but I would imagine that the only solution is to keep your api keys secret and the only way to do that is to access Parse only on the server like a traditional db. – George Mauer Mar 11 '15 at 14:46
  • Hi @GeorgeMauer, indeed, that's my understanding so far. This would defeat the purpose of Parse.com willing to eliminate the need for other backends. Let's wait for an official agent to provide feedback :-) – Jem Mar 11 '15 at 14:48
  • 1
    This is really a security flaw since even without this, I can DoS attack Parse.com (I won't do that, for obvious reasons). Should really be reported to the Parse.com devs instead of here. – AStopher Mar 11 '15 at 16:09
  • Hi @ʎǝʞuoɯɹǝqʎɔ, yes, but the suspected flaw is so huge that I can't imagine it's not handled somehow. Parse.com certainly has security experts with way more understanding than I do... which makes me think there is an actual solution, but haven't come across its description yet. – Jem Mar 11 '15 at 16:14
  • 1
    Parse employees seem to be more active on the google group than in here, so you might want to ask for an official response there, or even lodge a request/bug with Facebook about it. But you're right - this is an easy attack on any Parse app. A solution would be to put your keys behind a thin proxy to Parse, so they're not exposed in your JS, but injected on the way through. You can implement your own throttling and IP blocking this way too. – rickerbh Mar 11 '15 at 22:44
  • 1
    https://www.parse.com/questions/javascript-sdk-security https://www.linkedin.com/groups/Is-Parse-secure-solution-2204708.S.277308762 for reading... – Robert Rowntree Mar 12 '15 at 01:09
  • Thanks @RobertRowntree, corporate firewall blocks those groups so I'll post from home. I'll update this discussion with their input, in case you're interested to follow. That proxying seems a good solution, however, I doubt my current "security" skills are sufficient to make the proxy gloabally less failsafe than exposing parse keys directly :-) found "toobusy" for nodejs, looking into that. Any good advice about proxy security with NodeJS? Kind regards. – Jem Mar 12 '15 at 12:05

1 Answers1

1

Yes, your Parse JavaScript keys are public

They have to be defined inside your JavaScript files, which can be openly accessed.

It is not said that you can't try to hide your keys by applying the principles of

Security by Obscurity ;-)

You can encrypt your keys and place decryption function right inside your JavaScript. You can further make it harder to find by hiding that function in the middle of a large nasty script that nobody would enjoy, and then minify your JavaScript (which you should be doing anyway). I am sure it is possible to get even "more creative" and reach some reasonable perfection :-)

It remains, however, possible, in principle, for a sufficiently motivated hacker to reverse-engineer your program and get the keys. Still you can make it hard enough, so the hacker will likely look for easier targets, of which there is plenty as we know ;-)

Reduce potential harm by setting correct permissions

Whether you applied the previous principles or not, your golden rule should be to tighten your Parse (or any other sever for that matter) permission as much as possible.

This will prevent bad things like your data getting destroyed, which is worse than DoS attack.

That would still permit anyone know your keys to abuse them - not only by DoS - but also more unpleasant things like signing other people's as user and unleashing a stream of confirmation emails to the unsuspecting victims. And since you probably want to allow new users to sign, you can't really protect yourself from this abuse (except the "methods" of previous paragraph that is).

Parse's own statement

A few years ago I actually asked that question on Parse forum and their answer was that, should that happen, they would look into that.

Final idea

Finally, assume your site business is critical and you can't afford to wait from Parse in case that actually happens (it is not to say they would be slow - I really have no experience with that situation).

What you can then do is register several other application keys for a fall-back and keep the copy of your site, so you can quickly divert your users there. Or only divert some of them.

Dmitri Zaitsev
  • 13,548
  • 11
  • 76
  • 110
  • Hi @Dmitri, thanks for your detailed advice. I think you got it right all the way. – Jem Apr 29 '15 at 15:11
  • Obscuring your key does not prevent a user from simply executing the OP's script in the console of an already initialized app (assuming the app offers public authentication) – adamdport Oct 23 '15 at 15:58