I am surprised that, as I understand it, any app can potentially clone my Parse's Client KEY and App ID and act exactly as if it were my app, enabling and authenticating users on my app, having access to the same database and the same Cloud Code. So it is? Is there a way to avoid this?
EDIT:
My question is not related to privacy or data owned by the user. I read about the right way to use ACL, level permission of class, masterkey and so on.
But the question is how to prevent that another app cloning my KEY/ID can lean to the data of my app and do whatever we can make by my app, mixing its database with mine and also impacting on the request counter.
All the Parse Application and client keys (except for the master key) are considered public information and NOT secrets. This is clearly mentioned in the Parse documentation. There is no way to hide them and they will be part of your app/website and they can be easily retrieved by any user. This means any data in your classes with Public read access can be retrieved by anybody. Read Parse documentation on how to secure your app against malicious users.
Related
I have a project where one app needs to access multiple databases sharded across multiple firebase projects. Now since it's the same app, i can't use the same SHA1 across all the projects where i add the app.
I do not add any google-services.json files for any of the projects, instead i fetch the database url, the storage bucket info, the api-key and the appids for each project from my own server which keeps a track of all the sharded firebase projects.
My question is, with just this much information, can anyone just authenticate to firebase?
There's no SHA1 protection so is my db even safe even with the auth!=null rule? (since anyone can initialize FirebaseApp with this info and get a FirebaseAuth instance and sign in anonymously). In summary for this one, can anyone just make an app of their own, use the info and access/manipulate my database?
How can i secure my app if it's not secure with the current configuration
Yes, that should be enough information to create a web app that connects to your database.
But this should not be a problem if the database rules and auth providers are the right ones for your case. For example:
If you don't want anonymous Users to authenticate with your app, disable the option in the Firebase console.
If you want to give access only to a limited set of users without enabling new signups (or if you have special requirements for auth) then user a custom auth provider.
If you want to limit access to certain parts of your database (or need different user roles) adjust your database rules.
I hope that answers your question!
After a little research and a little brain storming, i came to the conclusion that Oauth domain which by default is localhost and the firebase-app domain will prevent anyone from directly authenticating to my Firebase app.
Even if the api-key and other info is exposed, as long as the service-account is hidden, the auth-domain will protect my app since the auth-domain will cause the authentication from a non-authorized domain to fail. Maybe I'll even want to remove the localhost in production :)
I have read about Parse server which was created by facebook , but I think there are serious security issues.
I can decompile other people apk and get Parse master key, appId and then I can connect this people parse server from my own application and can do whatever I want to do with his data which very dangerous
Even I can make while(true)loop and insert infinite data to the parse server.
So how can I connect any API in Android Studio securily?
You shouldn't put the master key anywhere publicly available. If it's in your APK, you're doing something dangerously wrong. Master key should only be an environment variable on your server.
Sure, you could get anybody's app id and client key (if they added one) by decompiling, but that's the same with basically any API. You need to use the security tools provided by Parse, namely CLPs and ACLs. You shouldn't have any data too sensitive on your server at all. I.e., you never need to store a user's actual payment information, you should use a payment API, pass any information needed to them directly from clients, and store the tokens they give you. I.e. with Stripe, there is a "public key" that is used on the client to talk to their secure server, pass credit card info, and create a card token, and you pass that card token back to your server, which can use the secret key, which should absolutely never be put in a client app, to create charges and things.
CLPs and ACLs restrict access to your objects. CLP (Class Level Permissions) are used to restrict entire tables. They have a cool thing called Pointer Permissions, so if an object has pointers to a user, you can set it to the user set on that field can access their objects. You can restrict public access so you can only get an object with the id, but not find it in a query. You can completely restrict read access, and you should restrict write access on most classes. Business logic goes on the server, you can verify a session token to make sure a user should be accessing an object and then use your master key to actually do necessary updates.
Parse-Server has all of the security implementation you need to protect your user's data. You just have to implement it properly. If you don't use CLPs and ACLs, anyone can decompile your app and get your entire database.
Also, Parse wasn't created by Facebook. It was acquired, then shut down and open sourced about a year or so later.
The Application ID is not a security mechanism and you must not ever use the master key in public applications as it allows you to bypass all of your app’s security mechanisms. It's a big mistake to store master key in the app.
Security must be provided to Parse Server by Class Level Permissions and ACLs (and all connections should be made with HTTPS and SSL).
In my experience, Class Level Permissions should rarely grant Public access (default behavior when creating a Class in Parse Dashboard). I only use Master key for testing purposes and to do some queries/savings in afterSave triggers and cloud functions.
I recommend reading the Parse's Security Guide to understand a bit better how to build a secure Parse API. Here is an important fragment that backups my answer:
The master key, on the other hand, is definitely a security mechanism. Using the master key allows you to bypass all of your app’s security mechanisms, such as class-level permissions and ACLs. Having the master key is like having root access to your app’s servers, and you should guard your master key with the same zeal with which you would guard your production machines’ root password.
You can store your API keys, Secret keys or any other important key information in .C file.
For that you have to use NDK.
You can follow this link for how to use the NDK to secure your file. You can also find GitHub demo app link at the bottom of the page.
Note: If you are using NDK it will increase your APK size.
The title doesn't really indicates what I mean:
I am searching for a secure way to save user data (a point system for a game - under no circumstances the user should have the ability to change his amount of points). And I stumbled across firebase, which seems pretty nice and easy.
But:
If I give the app the rights to directly write the users new points to the database it is pretty insecure, right? I mean, someone could decompile the app and get the keys from firebase so that anyone could write to the database, or am I wrong?
Also, what would be the best way to save those "new point" into a firebase realtime database?
Edit: I am already securing my app with pro-guard but that just makes it more difficult for users to get the key, I guess.
The Firebase configuration data in your app is not a security concern. It is simply information that your app needs to find its Firebase project on the servers. See Is it safe to expose Firebase apiKey to the public?.
To properly secure data you write security rules, which are evaluated on the server. With these you ensure that users can only read the data you want them to and that only authorized users can make valid changes.
In cases where security rules become more complex than is feasible, you can consider proxying the read/write through Cloud Functions for Firebase. With Cloud Functions your code runs on Google's servers, so you have to worry less about user modifying the code for malicious purposes.
its secure if you use cloud code. This way everything is going through the server to save it and a user has no way to change that unless they have access to your cloud code.
I'm trying to work out the best solution for a particular situation I'm in, and am having trouble working out the best option. It's a tricky setup, so might be a fun challenge for you Android experts! Here's my situation:
We have two Android apps already on the Play Store, and are working on another right now.
The two released apps are signed with the same keystore, but do not currently have a sharedUserId set in their manifest files.
The two released apps store a user's oAuth token in SharedPrefs, some product/content data in an SQLite DB, and some audio/video content in external storage (using getExternalFilesDir).
The apps are all separate oAuth clients/applications of our server (i.e. they all use different client ID and secret keys).
Our server is setup to only allow one oAuth token per oAuth application (i.e. Android app). e.g. if a user logs in to app A on one device, then logs into app A on another device, the first device's token will be invalidated and the app will receive a 401.
We've successfully implemented a single sign-on system on iOS by enabling shared keychain between the apps. If an app detects that another app in the group has a valid oAuth token, it can send that to our server and exchange it for a valid token for that app.
In the iOS version, we wanted to ensure that the apps didn't need to know about the existence of the other apps using hardcoded values per-app (e.g. if we release a new app in the future, other apps don't need to be updated to share/receive tokens with it), so we created an entry in the keychain containing an array of bundle IDs that had valid tokens, that all apps could access. When an app successfully logs in or exchanges a token, they add their own bundle ID to that array. Any newly installed app could find a bundle ID from that array, and use that it as a key for loading the token details for that app, which it would then exchange for its own fresh token.
We want the token exchange to be automatic and not require input from the user.
I hope that all makes sense!!! Please let me know if not.
I'm now trying to work out the best method for storing oAuth tokens (plus some additional data such as email address to go with it) on Android so that other apps owned by our account can access them in order to exchange for a fresh token.
I've looked into using the following, but am unsure of the best route:
SharedPreferences along with sharedUserId
AccountManager (https://developer.android.com/reference/android/accounts/AccountManager.html)
Android Keychain (https://developer.android.com/reference/android/security/KeyChain.html)
ContentProviders
The problem with option 1. seems to be that setting the sharedUserId after first release will lose access to all of the data (see http://java-hamster.blogspot.jp/2010/05/androids-shareduserid.html). This is not a nice thing for our users.
Option 2. (AccountManager) could be a good option, but if we want to store the tokens separately (per-app), but want any other apps we make to access their tokens, I'm not sure how we'd do that.
Option 3... is it possible to do what we need with Keychain?
If I understand correctly, option 4 would need each app to have its own ContentProvider? I'm not sure how that would work for our requirements.
If anyone has gone through this kind of situation and could share some insights and recommendations, I'd really appreciate it!
ContentProvider is probably your best best. I won't be able to provide the whole code for you to do this, but this is generally how I see it working:
Each app creates a content provider that exposes their own API token;
Each app tries to acquire and query (sequentially until successful) all the other content providers before requesting a login;
If app X is able to acquire and retrieve the token from app Y (via Y's content provider), then store it in app X and use it;
Side notes:
This is very sensitive information, so you should enforce security. Your content providers should only be accessed by other apps signed with the same key, they should have only read permissions and you should create your own custom permission as well.
The content provider does not need to access an sqlite database. It can access whatever your using to store the token (which I hope is stored in a secure way, but I'll leave that to your own judgment)
Useful links:
How to create a custom content provider
How to secure your content provider
Example of content provider that retrieves data from shared preferences;
AccountManager is meant to solve the exact problem that your are commenting. Here is a good tutorial to work with it:
http://blog.udinic.com/2013/04/24/write-your-own-android-authenticator/
Just be sure that you sign all your apps with the same keystore, because this is the only thing that might complicate things (a lot).
Using preferences will lead you into a problem as all that you store in the main thread is not guaranteed to be there in a Service (like a SyncAdapter). There used to be a trick for this in the form of flag (MULTI_SERVICE) but was deprecated in api 23.
ContentProvider is of course possible (its too generic) but AccountManager will help you to cover the corner cases related from refreshing tokens and other interesting stuff.
I'm developing an app that will use text messages to verify a user's telephone number, the usual "enter code" routine.
After reading a little bit it seems like a bad idea to store the private keys for whatever 3rd party I'll use in the app (twilio, nexmo, etc). Somebody could reverse engineer these from my binary and use them in their app.
However, having these on the server doesn't help either, somebody could just reverse engineer my server's endpoint that I use to send text messages and use that instead.
E.g. I could reverse engineer WhatsApp and get the private keys or API endpoints that they use for telephone number verification and just use that in my app, saving me thousand of dollars.
Any ideas on how to protect myself against such an attack?
Hiding API Keys on the server
However, having these on the server doesn't help either, somebody
could just reverse engineer my server's endpoint that I use to send
text messages and use that instead.
Yes it does help a lot.
If somebody gets access to the keys to your web service, they can only do, what your service allows them to do. This is a very good idea to have a web service that encapsulates all the 3d party keys and API - it's way more secure.
Nobody will ever get access to your sensitive keys, that'll allow them to do everything.
For example the 3rd party API allows deleting - your server wrapper API will not allow it.
Moreover, you can add any extra logic or alerts for suspicious behavior.
Hiding API Keys in the app
If somebody sets their mind to it, there's no way you can prevent getting your keys reverse engineered from your app. You can only make that harder. Computer security should never be about "how hard/complicated it is to do", but in this case we have no choice.
Ok, so you have to hardcode the API keys into your source files. It can be easily reverse-engineered.
You can obfuscate your keys, so that they can't be read directly. The result will be that they'll be scattered in a compiled file, rather than comfortably being placed in one place.
On iOS you can use something like this.
On Android you can use DexGuard, or any other way to obfuscate a string.
Encrypting the keys
Another layer of making it hard for hackers is to encrypt the keys.
Here's an example for iOS.
You can do the same for Android.
Perfect Scenario
Ok, so let's say you have a 3rd party API for video management.
The hacker wants to delete all videos on the server, because the 3rd API allows that.
First he has to glue up all the scattered strings in the file. If he manages to do that, he has to find a way to decrypt that.
Even if he manages to decrypt that, that'll give him the API keys to your server and your server and your server only allows to upload videos, not delete them.
I think firebase functions can help us in hiding the third party API keys.
The proposed solution-
Store API keys in firebase as environment variables.
Make a firebase https function that answers to only the authenticated users. If an authenticated user requests it, the secret API key from the firebase environment variable is returned as the response.
Android app does an anonymous login into firebase for the first time, obtains the token.
This token is used as Authorization token in headers while requesting firebase https function. The firebase function would be something like https://us-central1-{your_project_name}.net/{function_name}
I have discussed the approach in detail in this blog and made a sample project