3

I've used Parse to create an application for iOS using the iOS SDK downloaded from the Parse.com website.

In order to create this kind of application the ApplicationID and ClientID keys are both embedded in the iOS app and sent from the app to the server when the application is used. This essentially puts the ApplicationID and ClientID in plain sight so any user can write a small program which would repeatedly call the various Parse apis of my application.

I have followed all the security advise in the parse tutorials and all the data has appropriate roles and ACLs.

HOWEVER a single unsophisticated user could bring down my entire application simply by calling the login api of my parse app more than 30 times per second.

Am I missing something or is this a FATAL flaw in using Parse.com as a backend from an iOS app?

Does anyone have a solution to this problem?

Charles
  • 50,943
  • 13
  • 104
  • 142
Brett Hannah
  • 4,307
  • 4
  • 30
  • 33
  • 3
    Not really sure this is a programming question. Don't parse run a forum where this would be better answered? – trojanfoe Jul 07 '14 at 10:37
  • Agreed that this isn't a question for here. But that person would have to know the `app token` and `app secret` for your app before being able to run any APIs against it – Fogmeister Jul 07 '14 at 10:39
  • This question appears to be off-topic because it is about Parse.com - it should be directed to their support forum – Paulw11 Jul 07 '14 at 10:40
  • Hi trojanfoe, thanks for the comment. I've edited the question slightly. I'm hoping that someone has a technical solution to this problem (or I'm just being an idiot and someone can point out my mistake). There is a parse forum and similar questions have been asked but a solution to the problem has never been provided. – Brett Hannah Jul 07 '14 at 10:41
  • 1
    @Fogmeister - that information is in the binary, which can be reverse-engineered. Simple obfuscation of these strings would go a long way to mitigating the risk however – Paulw11 Jul 07 '14 at 10:41
  • Hi all, I'd like to think this is a programming question since it encompasses a large number of technical issues which I'd hope could be solved with a technical solution. – Brett Hannah Jul 07 '14 at 10:44
  • @Paulw11 - thanks, I though about obfuscation, but since ultimately the AppID and clientID are sent as part of the request then simply monitoring the network traffic reveals the IDs even if they are obfuscated in the binary. – Brett Hannah Jul 07 '14 at 10:46
  • Not that I've used parse.com, so I don't understand all the details, but this question on their (stackoverflow-like) system might help: https://parse.com/questions/securing-application-id-and-api-key-in-javascript – trojanfoe Jul 07 '14 at 10:54
  • You should also verify the digital certificate that Parse.com sends. Even this isn't foolproof because you can't trust the device, but it makes it a lot harder. I also suspect that Parse.com will have mitigations on their side - detecting a flood of requests for example and not counting authentication requests - without authentication a request doesn't count against your app – Paulw11 Jul 07 '14 at 10:59
  • @trojanfoe - Thanks for the link. You'll see from the top of the link that Parse.com no longer run a forum and are instead directing users to ask their questions on Stackoverflow instead, hence how I ended up asking here in the first instance: **"You're looking at our forums archive. If you're looking for help, head over to the Parse Developers Google Group or check out the parse.com tag on Stack Overflow."** – Brett Hannah Jul 07 '14 at 11:07
  • 1
    use proguard to make sure that the strings disappear. remember that TLS encrypts headers and that all API access is via HTTPS. dont think u need to worry so much about headers. – Robert Rowntree Jul 07 '14 at 15:28
  • Thanks Robert. Proguard looks like a good product, I'll definitely use it on future projects. – Brett Hannah Jul 07 '14 at 16:23
  • 1
    @RobertRowntree. Parse makes all requests via HTTPS which prevents a third party intercepting the data. But it doesn't stop a user of the app setting up their own proxy, adding their own certificate to the trust store and then viewing all traffic between the app and parse in plain text, thus extracting the AppID and ClientID. – Brett Hannah Jul 07 '14 at 16:29
  • Same security hole with app- engine AFAIK where app id accompany https reqs. – Robert Rowntree Jul 07 '14 at 18:25
  • 1
    @RobertRowntree Google App Engine doesn't use app id to accompany requests, because each app has it's own url, app traffic is not distinguished by an app id on the request. Additionally App Engine does not charge for incoming traffic so any malicious incoming requests can be filtered out before impacting on your quota of resource use. – Brett Hannah Jul 09 '14 at 09:06
  • 1
    @BrettHannah did you ever get an answer from Parse on this? Last night I ran a test app through Charles, told Charles to repeat the login call 1000 times, and immediately hit the rate limit. I could do this to any of their advertised customers if I wanted to. Horrible flaw. – ChrisH Aug 27 '14 at 17:54
  • @ChrisH. Nope. I've asked them repeatedly and they continually give vague answers about it not being a problem when quite clearly it is. Appears to be a fundamental flaw with using Parse. – Brett Hannah Sep 02 '14 at 20:27
  • Possible duplicate of http://stackoverflow.com/questions/28989601/denial-of-service-attack-on-parse-com-app – Dmitri Zaitsev Apr 25 '15 at 15:33

1 Answers1

0

You can always reduce the chance substantially by applying 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 ;-)

See also here for more ideas.

Community
  • 1
  • 1
Dmitri Zaitsev
  • 13,548
  • 11
  • 76
  • 110