While testing the security of one of our product, a web application, using the REST API of Firebase we got surprised when we realised that refresh-tokens never expire in the V3 of the Firebase implementation, allowing any refresh-token to create new tokens forever.
While local-storage seem a reasonably safe solution today, we are concerned by the possibility that it could fail tomorrow, even for a short amount of time, and that we cannot stop someone from using any of these refresh-tokens.
Two factor authentication will help mitigate the issue, but the first step would become compromised nonetheless.
Is there a way to blacklist tokens, or similar behaviour, with Firebase, without handling all tokens exchange, such as minting, ourselves? We could not find such feature when going through the doc.
Any advice appreciated.
Authentication sessions don't expire with Firebase login. But the ID token will have to be refreshed hourly, to keep access to the services. If you disable an account, refreshing the token will fail and the account won't be able to access services anymore. There is no way to invalidate individual tokens.
Firebase recently implemented revokeRefreshTokens() inside the admin sdk. Although this will not let you kill an invalid JWT, it does allow you to prevent a refresh of the token (from my testing so far at least) and it allows cleaner control flow inside firebase database.
See Admin Manage Sessions For rough examples
Related
Could someone please explain to me why a bad actor could not create the following disruption for potential new users to my app?
The bad actor:
Obtains a list of emails from the dark web or some other nefarious source.
Acquires my Firebase keys by inspecting my app javascript -- yes my app is minified, but it would still be possible.
inserts malicious javascript code into my app sources on their local browser. The malicious code uses the Firebase sdk and my app keys to create accounts for each email address.
While there is no possibility that the bad actor could gain access to validated accounts;
nevertheless, creating these accounts would generate unsolicited email verification requests to the owners of the emails and it would also interfere with a smooth account-creation experience for those users when they actually do want to signup.
Am I missing something here?
firebaser here
As Dharmaraj also commented: the Firebase configuration that you include in your app is used to identity the project that the code should connect to, and is not any kind of security mechanism on its own. Read more on this in Is it safe to expose Firebase apiKey to the public?
You already in your question noted that creating a flurry of accounts doesn't put user data at risk, which is indeed also correct. Creating an account in your project does not grant the user any access to other user accounts or data in your project yet. If you use one of Firebase's backend services, you should make sure that your security rules for that service don't do this either.
The final piece of the puzzle is that Firebase has many (intentionally undocumented or under-documented) safe guards in place against abuse, such as various types of rate limits and quotas.
Oh, and I'd recommend using the local emulators for most of your testing, as that'll be faster, doesn't risk accidentally racking up charges due to a quick coding mistake, and (most relevant here) doesn't have the rate limits in place that are affecting your e2e test.
In short: In GCP credentials can be restricted with application restriction and with API restriction, but Identity Toolkit API cannot be restricted on Expo mobile application.
-In web both restrictions work
-On android/iOS API restriction works but (as I have tested, correct me if I'm wrong) application restrictions does not
Now if using email/password authentication there is an issue.
There is a huge insecurity here as if anyone gets to know your API key (you define in initializeApp and so you connect to Firebase with and so use with Identity Toolkit API).
They can only by knowing that key call Firebase Auth REST API "Sign up with email / password" from anywhere and create users for your project!!
Am I wrong, missing something or can this be prevented somehow?
Things you can do to prevent this:
In "GCP>credentials>Identity Toolkit API" you can lower "Queries per minute" and "Queries per minute per user"
You can in "Firebase>Authentiction>Sign-in method>Manage sign-up quota" lower the quota from same IP address to minium (but does this help in case of android/iOS application?)
But there is no completely secure solution unless you can application restrict your API key as far as I know.
I got the following answer from Firebase support and since there has not been answers I will add this as correct answer for anyone looking solution for same thing or seeing this question.
First of all, I would like to thank you for choosing Firebase to
implement your application. I know that these kinds of situations
could be frustrating, let's work together to provide the best solution
for you.
I have checked your case and I would recommend that you reinforce your
Security Rules, because this is not a security risk, as long as you
secure access to the data within your project correctly for your
requirements, as it is mentioned in this external entry.
We don’t have a way to know the origin of those emails, even if they
were created by real users through your app, but if you identify fake
accounts you can use Cloud Functions to delete all emails registered
with that pattern using Auth triggers. Alternatively, you can delete
the accounts after an established time without activity using Schedule
Functions.
Additionally, if you don’t want to have users on your application, you
would probably need to use the Admin SDK and authenticate the
application by service account instead.
I'm currently running a project that uses Firebase Hosting and Firebase Functions. Both functions apparently use some cookies for their own reasons, but I can't seem to find a way to 'disable' them for my website visitors.
All around, I'm not very well informed on GDPR laws, but I'd like my webpage to comply with those, by giving users the chance to opt out of cookies.
Is there a way to disable those cookies? And if not, is it possible that they are already GDPR compliant?
Cheers.
The cookies used for Firebase are specifically for Authentication reasons only, Firebase doesn't track personal information or data but rather stores a randomized Javascript Web Token to re-authenticate a user when your app gets refreshed or reloaded.
Additional client-side data is used for caching the database to increase read performance but doesn't expose or track a user by any means either.
So I have an app where I have enabled google authentication in my firebase project. 25 people I know were authenticated. When I logged in the backend I saw atleast some 80 entries with some weird sounding email addresses which should not be there. I had to delete all the entries manually, known and unknown ones (didn't needed any after sucessful testing). Now that I want to go live, I am really concerned as to how unknown entires entered my firebase authentication records?
This has recently happened 'again' to another new app/project of mine. This time I disabled that unknown email address and took a screenshot (attached).
I really really need to know and understand how safe is data on firestore. If someone can manage to 'hack' the Authentication part and add thir email to Authenticated list of users they may also be able to penetrate the database somehow in future. Please help me in understanding what is happening?
While researching on this, I could only find this similar question but the answer was just not enough explanation for me.
Unknown user in my firebase user authentication (Flutter/firebase)
firebaser here
Since the configuration data for your project is embedded in the application that you send to your users, any user can take that configuration data and then start calling the API with it. This is not a security risk, as long as you secure access to the data within your project correctly for your requirements.
See Is it safe to expose Firebase apiKey to the public?
What it means to correctly secure access to your data is hard to answer, as it depends completely on your use-case.
For example: the content-owner only access security rules allow a user to enter data in the database, and then they can access the data they entered. With these rules there's no risk if anyone uses the API (and not your app) to do the same. The security rules will ensure they only can access data they're authorized for, no matter what the source is the API calls is.
It may be related to the pre-launch report.
https://support.google.com/googleplay/android-developer/answer/9842757?visit_id=637478112313064713-650300184&rd=1#signin
Step 1: Provide test account credentials if your app has a sign-in screen
If your app has a sign-in screen and you want the crawler to test the sign-in process or the content behind it, you need to provide account credentials. Note: You do not need to provide credentials if your app supports 'Sign in with Google', which enables the crawler to log in automatically.
So I guess it is safe.
The user willwhiteapple#gmail.com is the apple testing when your application is in the process of validation from apple before deploy to TestFlight .
I have created an ionic4 firestore mobile app. It's a SaaS application it has monthly subscription payments. My problem is how could I sell the app using firestore's offline capabilities? I mean making the app work offline adds value to my product but the users can use it for ever, with just offline caching. How can I stop users from using it after a month? Thank you.
If you wanted the opposite (allowing the user to continue using the app offline, but not online, after their subscription expires), you could do so by modeling this in the server-side security rules of your database.
But security rules are not applied while the client is offline. So there's no way to use security rules to reject users without a subscription.
This means you'll have to find a way to lock them out of your app itself, typically by storing (in the offline cache) until when their subscription is valid, and then refusing to start the app if that date is in the past.
A malicious user might be able to work around this, and access the data without your app. Since you're not paying for any database services at this point, that seems a decent trade-off. But if you don't think so, you can start looking at encrypting the data, which makes it harder for users to access the cache without your app. At this point you're pretty much in an arms race with malicious users though, so I'd seriously consider if the loss in potential revenue is worth the effort.