A hacker was able to create users in my client side based firebase site, I was restricting account creating by some sign up conditions on user's signup form data, I think he just injected signup code,
I immediately disabled authentication and removed the malicious accounts
If I used firebase cloud functions, will this hack still be able to create accounts, since firebase configuration was available to any client
are there any other actions ?
Update 4-9-2022
as temporary solution until using cloud functions, I made use of
making conditions using
https://firebase.google.com/docs/database/security/rules-conditions
if a user was created bypassing my logic I will make rules to disallow him from accessing certain paths
If you didn't do this already. You could fix this by adding some email verifier functionality. Or maybe try adding a captcha
Also check out: https://firebase.google.com/docs/auth/web/email-link-auth
Blocking the user by IP-address is pretty useless, so I can't really come up with another solution.
One question that you could ask yourself is, What is the reason they are doing this? If it is nothing too serious you could just accept and delete all those accounts after the "hacker" stopped making accounts.
Related
I'm trying to build an app that works like a classic videogame, with some challenges that the user must complete in order to advance. Based on how the user solves the puzzles, he/she will gain XP points, badges etc. The user can quit the app and come back later, with an authentication system.
I'm planning to use Firebase Auth for authentication and Firestore for the database. It's the first time I use Firebase services in (somewhat) production environments, but I've been experimenting a lot with their services lately.
Firestore will be used to store a set of data for every user, but mainly his/her score. I'm somehow familiar with Security Rules in Firestore, and know how to make sure that only authenticated users can write to the db, perform data validation before giving write permissions etc.
However, there's one problem I cannot come up with: how can I be sure that the (authenticated) user will not use the browser console, or a custom API call to update his/her points and write them to the DB? Like in the first part of this video: https://www.youtube.com/watch?v=b7PUm7LmAOw&t
To sum up: my expected result would be that the (authenticated) user could update his/her score on my Firestore DB only by using the UI (i.e. solving challenges) and not by making a direct call to the DB. I thought of some other solutions (e.g. sending only user response - like answers to a quiz - to the DB and then updating the scores server-side with Cloud Functions), but it seems to me that I'm over-complicating a simple issue.
I've watched and read a good amount of guides on security in Firestore: they do a good job explaining how to secure an app from un-authenticated hackers, but I am yet to find a guide on how to defend the app against unwanted behaviour from authenticated users.
Thank you in advance for any guidance on this, deeply appreciate it. Stay safe :)
UPDATE: looks like the only way to manage data flow to the DB when you can't "trust" the authenticated user is using Cloud Functions. Thanks!
Listen to score, points, badges in real time using Firestore. You may set the security rules to these fields as READ ONLY for an authenticated user, setting write permission for a service user (that will be used in your cloud functions).
Send Quiz answers using a cloud function, that will be processed using your service authenticated user (with write permissions to the collections).
Thus, your cloud function may be responsible for checking answers and preventing user abuse from console and other methods.
In the firebase API
https://firebase.google.com/docs/auth/web/manage-users
we can delete users, but how could we prevent users from simply registering again, in the GUI for firebase we have the option to disable users , how could we do this in the program, for example if we are building a admin panel that checks posts for a listing site that have been reported, and we want to disable the creator or the reporter for spamming as part of availiable actions.
Thanks.
I develop in react if that changes the answer.
To prevent the user from re-registering, you should disable account instead of deleting it. This will prevent the user from signing in again, and from refreshing their ID token. If you want to do this programmatically, have a look at updating a user with the Admin SDKs. For example, in Node.js it'd be:
admin.auth().updateUser(uid, { disabled: true })
Keep in mind however that even after disabling the account, their existing ID token will remain valid until it expires (typically within an hour), and cannot be revoked. If you want to prevent them from posting in the meantime, you'll also want to keep a list of blacklisted/blocked UIDs somewhere, and check against that list before allowing them to write/access the data.
You will not be able to programmatically disable a user from the frontend of your app. You will need a backend, and use the Firebase Admin SDK to update the user account to become disabled. The API is updateUser.
Well they can always register again (in case the website is public/ not invite-only), with completely different credentials.
You can do a matching of the new data and existing blocked users, and if it matches above a threshold, flag them.
And you can improve your reporting, the faster you detect a user who should be blocked, the better.
Can't say I'm super familiar with Firebase but ill try and help (can't hurt).
Have you tried to blacklist the IP of the user in question?
Hope I helped :)
Have a good day!
I'm creating a new web-app that's connected with Firebase. Now, I know that javascript functions can be run from the console.
Can I prevent someone from creating Firebase accounts?
I can't disable email/password authentication as that would make my app unusable(people won't be able to log in).
The function createUserWithEmailAndPassword() can't be restricted as far as I know.
I've had one idea of a kind-of fix, but even that doesn't feel safe.
My idea is to restrict so the function can be called only by an authenticated user. I would restrict this on the front end since it can't be done through firebase.
I would then obfuscate the code so they can't change it and still have my authorization data.
The situation is that I have a website, where at the end the user can order with filling a form, but no registration or log in is required, to be more specific, there's no possibility to register or log in. When the form is filled, with the submit button I want to validate the input with a function, and if they are valid, send it to Firebase. There are a few problems:
there's no possibility to authenticate the user, I need to set the Firebase security rules as "open", so everybody can write and read data to the database (but it may be a good solution to set as everybody can write, but just I can read data.
I read a bit about the config variable, and there's no good possibiity to hide that, so if somebody write a simple js program, and set the config as it's in my file, it can do whatever it want with the database
I was thought about that is it really the best solution to read the users input as order, I was thought about that maybe js can somehow send me the data to my e-mail address, but after careful research, I can't found a possibility to that. Anyways, it's sure that there's a solution to the Firebase problem. What I want is to set the only possibility to write to the database through the website, and read the data just through the Firebase Console.
There's not much you can do if you aren't authenticating your users, I guess the best option would be to set up write rules to protect the integrity of the data being saved (so even if someone with access wrote to it they'd have to follow a structure): https://firebase.google.com/docs/database/security/securing-data and set read rules to nobody.
Another method may be to have an API on a backend server which makes sure all requests are coming from your website only before saving it to firebase. This way you won't have to expose your firebase config.
In addition to #AlchemistShahed's answer, I'd recommend checking out Firebase's anonymous authentication. This gives each user an ID, without requiring them to specify any information. It's pretty much a persistent session ID, with as little code as:
firebase.auth().signInAnonymously()
By embedding this (anonymous) user's UID into the data they write to the database, you can easily detect when a single user is flooding your queue with data.
You could write a cloud function that would be called on form post, that function would check and sanitize data before inserting data into Firebase. Since data insertion would be done from the server side, no config would be present client side. Then set security on Firebase so only you can read.
You can also check those links, you might find something else in there.
Here's a link to some common use case for Firebase rules:
https://gist.github.com/codediodeio/6dbce1305b9556c2136492522e2100f6
Here's a link to Firebase security doc: https://firebase.google.com/docs/database/security/
I'm a bit confused. I am trying to provide a simple Google Authentication sign-on.
I would like to use Google's recommended method using the client-side flow: https://developers.google.com/+/web/signin/add-button
If I use this method, how will I keep a user logged in as they move from page to page. I know I can't create PHP session via Javascript.
How can I use the client-side flow and keep a user signed in. I am using PHP on my server.
After spending a few weeks researching, I now understand that I cannot just set a php session variable and stop using oAuth2. I realize that everything I need to get information from Google, I must prove that I have still authenticated that user.
Also, I have come to understand that unless you force prompt, Google will not resend a refresh-token. To provide the best user experience, you must capture the token at first login and then re-use the token to make calls without having to force prompt. This token must be stored in a secured location such as a database for each user.