I have an http function, that uses nodemailer and gmail to send emails when invoked,
I use it for a contact us form on my website,
I find that I'm able to send as many as I can from Postman, and similarly can just set up a script that keeps on firing that function without limits
I've looked everywhere to find a way to restrict access, but couldn't find anything that made sense as a simple straightforward solution
Related
I am trying to implement a notification system for handling notifications similar to friend request notifications. For example, I write the email of the person I want to send a friend request to. then click on send request. I am confused as to after that, what exactly should happen?
Right now I am thinking that on clicking send request, I would create a document in cloud firestore in a 'notifications' collection, which would then invoke a cloud function that sends a push notification to the user with that email. The user now has the option to accept or deny the request. Choosing any of those actions would update the notification document which will again invoke a cloud function that would add both users to each other's friends list and notify the first user.
So my questions are: -
Is this method reasonably good to be implemented in a production app since it is involving many cloud function invocations and document read and writes? Or even better question - How would you implement something like this in a production-grade app?
Is there any other method that is secure (in the sense that no one should be able to wreck this process by changing the code on the frontend) and efficient (less read/writes/invocations)?
Can this be done without creating any document whatsoever? Purely by cloud functions? Then would it be able to capture other user's response to friend request and do the necessary changes?
For the problem you are describing I would approach it in the say way you are doing, and in fact there are not that many operations going on here, since you would have 2 Firestore writes and 2 invocations of cloud functions, not to mention that the second invocation could take a long time to be fired depending on the user's actions, so you don't need to be more efficient than that.
To you final question I would say that it would be difficult to have this implemented without information going through Firestore because you need to store the acceptance of the friend request, and for the same reason mentioned above, you need to store that information somewhere, even if temporarily.
I know I'm late but maybe this will help to someone else.
My way adding sent - receive friend request system is following:
For example:
me:
{
name:'John',
id:'20'
};
stranger:
{
name:'Lucas',
id:'50'
}
When I click add friend (on stranger) I will call function:
addDoc(doc('users', stranger.id, 'receivedFriendRequests'), { user:me });
This function will add ME into his receivedFriendRequests docs so he will be able to get that docs and check users who sent request to him.
So, in notifications Component you have to just get your receivedFriendRequests` docs and map all users and make function to accept friend requests for each of them.
When you click accept you need to delete that user from receivedFriendRequests and store both users in "friends" collection. You can do it in your own way, but I give the best example, in my opinion.
I'm trying to implement my own way of resetting user password for my mobile app. I've come to an idea to use cloud functions as I don't want anything other than Firebase working with my app. The problem is I will need to invoke three cloud functions to reset user password. First one will contain only user's email, second will contain code obtained by user from his password reset email and his email to check if code is valid and third one will contain his email and new password to set from cloud function.
The problem arise when I think about ways to pass this information into cloud functions. I know I can use URL parameters or just send it using POST method. But package that I would like to use to communicate with cloud functions doesn't support any other option than passing URL parameters to cloud function. I know I can write my own HTTP request to pass information using post but I'm thinking if there is any problem with sending this information using URL parameters. It's all sent over HTTPS which should guarantee obscurity of this data. I know that it still can be logged on server, and I don't know if Firebase store logs of cloud function requests with full URL parameters part visible. If yes, it would be big security issue with my app.
So, there are my questions:
Is there a security issue with passing sensitive information through
URL parameters?
Should I create my own solution using plain HTTP requests to pass sensitive information using POST?
Does anyone know if Firebase stores logs with visible URL parameters?
Is this even good idea to use cloud function for this matter? Maybe I should handle it differently?
Just to answer this question for future people like me:
like Renaud Tarnec said in his comment. SSL certificate by default ciphers all URL parameters. So it's safe to pass information this way. Firebase DOES NOT store logs with visible URL parameters when you call cloud functions. It only stores an ID of called function in your logs, so it's not a security threat.
I already use ReCAPTCHA for Android apps client-side (I've also implemented, of course, its server-side verification).
However, this ReCAPTCHA is implemented only in one activity. But, of course, hackers can modify the app. For example:
they can simply remove ReCAPTCHA from all activities,
or start another activity that would not have ReCAPTCHA implemented; it's the case btw: I didn't implement ReCAPTCHA in each activity because it's useless according to the first problem I've just mentioned.
So I would want to detect bot and spam requests in Cloud Functions, then in Cloud Firestore, then in Cloud Storage, for the following accesses: read, write, function call. It'd allow me to prevent unwanted contents from being saved in Firestore for example (spamming messages, etc.), and to avoid overreaching my monthly billing quota (because of spam requests to Firestore for example).
Is it possible? How?
There is no "spam detection" for these products. Your security rules will determine who can access what data. If you don't have security rules in place, and allow public access, then anyone will be able to get that data, and you will be charged for it when that happens. This is the nature of publicly accessible cloud services.
If you want more control over the data in these products, you could stop all direct public access with security rules, and force clients to go through a backend you control. The backend could try to apply some logic to determine if it's "spam", by whatever criteria you determine. There is no simple algorithm for this - you will need to define what "spam" means, and reject the request if it meets you criteria.
Google does have some amount of abuse detection for its cloud products, but it will likely take a lot of abuse to trigger an alert. If you suspect abusive behavior, be sure to collect information and send that to Firebase support for assistance.
Just thought I'd add that there is another way to restrict access to Cloud Functions.
Doug already described Way 1, where you write the access logic within the cloud function. In that case, the function still gets invoked, but which code path is taken is up to your logic.
Way 2 is that you can set a function to be "private" so that it can't be invoked except by registered users (you decide on permissions). In this case, unauthenticated requests are denied and the function is not invoked at all.
Way 2 works because every Firebase project is also a Google Cloud Platform project, and GCP offers this functionality. Here are the relevant references to (a) Configuring functions as public/private, and then (b) authenticating end-users to your functions.
When working with Firebase (Firebase cloud function in this case), we have to pay for every byte of bandwidth.
So, i wonder how can we deal with case that someone who somehow find out our endpoint then continuous request intentionally (by a script or tool)?
I did some search on the internet but don't see anything can help.
Except for this one but not really useful.
Since you didn't specify which type of request, I'm going to assume that you mean http(s)-triggers on firebase cloud functions.
There are multiple limiters you can put in place to 'reduce' the bandwidth consumed by the request. I'll write a few that comes to my mind
1) Limit the type of requests
If all you need is GET and say for example you don't need PUT you can start off by returning a 403 for those, before you go any further in your cloud function.
if (req.method === 'PUT') { res.status(403).send('Forbidden!'); }
2) Authenticate if you can
Follow Google's example here and allow only authorized users to use your https endpoints. You can simply achieve this by verifying tokens like this SOF answer to this question.
3) Check for origin
You can try checking for the origin of the request before going any further in your cloud function. If I recall correctly, cloud functions give you full access to the HTTP Request/Response objects so you can set the appropriate CORS headers and respond to pre-flight OPTIONS requests.
Experimental Idea 1
You can hypothetically put your functions behind a load balancer / firewall, and relay-trigger them. It would more or less defeat the purpose of cloud functions' scalable nature, but if a form of DoS is a bigger concern for you than scalability, then you could try creating an app engine relay, put it behind a load balancer / firewall and handle the security at that layer.
Experimental Idea 2
You can try using DNS level attack-prevention solutions to your problem by putting something like cloudflare in between. Use a CNAME, and Cloudflare Page Rules to map URLs to your cloud functions. This could hypothetically absorb the impact. Like this :
*function1.mydomain.com/* -> https://us-central1-etc-etc-etc.cloudfunctions.net/function1/$2
Now if you go to
http://function1.mydomain.com/?something=awesome
you can even pass the URL params to your functions. A tactic which I've read about in this medium article during the summer when I needed something similar.
Finally
In an attempt to make the questions on SOF more linked, and help everyone find answers, here's another question I found that's similar in nature. Linking here so that others can find it as well.
Returning a 403 or empty body on non supported methods will not do much for you. Yes you will have less bandwidth wasted but firebase will still bill you for the request, the attacker could just send millions of requests and you still will lose money.
Also authentication is not a solution to this problem. First of all any auth process (create token, verify/validate token) is costly, and again firebase has thought of this and will bill you based on the time it takes for the function to return a response. You cannot afford to use auth to prevent continuous requests.
Plus, a smart attacker would not just go for a req which returns 403. What stops the attacker from hitting the login endpoint a millions times?? And if he provides correct credentials (which he would do if he was smart) you will waste bandwidth by returning a token each time, also if you are re-generating tokens you would waste time on each request which would further hurt your bill.
The idea here is to block this attacker completely (before going to your api functions).
What I would do is use cloudflare to proxy my endpoints, and in my api I would define a max_req_limit_per_ip and a time_frame, save each request ip on the db and on each req check if the ip did go over the limit for that given time frame, if so you just use cloudflare api to block that ip at the firewall.
Tip:
max_req_limit_per_ip and a time_frame can be custom for different requests.
For example:
an ip can hit a 403 10 times in 1 hour
an ip can hit the login successfully 5 times in 20 minutes
an ip can hit the login unsuccessfully 5 times in 1 hour
There is a solution for this problem where you can verify the https endpoint.
Only users who pass a valid Firebase ID token as a Bearer token in the Authorization header of the HTTP request or in a __session cookie are authorized to use the function.
Checking the ID token is done with an ExpressJs middleware that also passes the decoded ID token in the Express request object.
Check this sample code from firebase.
Putting access-control logic in your function is standard practice for Firebase, BUT the function still has to be invoked to access that logic.
If you don't want your function to fire at all except for authenticated users, you can take advantage of the fact that every Firebase Project is also a Google Cloud Project -- and GCP allows for "private" functions.
You can set project-wide or per-function permissions outside the function(s), so that only authenticated users can cause the function to fire, even if they try to hit the endpoint.
Here's documentation on setting permissions and authenticating users. Note that, as of writing, I believe using this method requires users to use a Google account to authenticate.
I'm trying to write a function that will check to see if an email is registered with my Firebase app (with Javascript/Web), before proceeding with the sign up process (if the email isn't registered).
I created a node named active_emails which I wanted to populate with registered emails (like an array). I was going to check the email against this list and if it didn't exist then I would allow the user to proceed with the registration process.
I see from the answer here: Proper way to store values array-like in Firebase that Firebase creates keys inside the array. So a normal Javascript array check won't work. I understand how the answer above works, but I was wondering, since I'm essentially doing a look up on the emails of registered Firebase users, is there another way to do this check?
Am I correct in thinking that the answer above requires Firebase to compile and then send an array of emails back to the user client-side? This seems like it might affect performance (if there are hundreds of thousands, or millions of emails on file), and would it expose all user emails to the client? Is there another way to check if a user is registered or not, maybe something like attempting a registration and then catching a duplicate email error (although this sounds like a messy way to go about this).
The top answer here: How to find out if an email is already registered with Firebase Simple Login? suggests using fetchProvidersForEmail as a way of checking to see if an email is registered, but that answer is for android and I don't know if it's possible to do such a thing with Javascript/Web.
I've tried to integrate this method here:
function checkEmail(){
firebase.database().ref().fetchProvidersForEmail("emailaddress#gmail.com").once("value", function(snapshot) {
console.log(snapshot);
});
}
But it shows the error: firebase.database(...).ref(...).fetchProvidersForEmail is not a function. Does anybody have any ideas on the best way to go about achieving this check?
Thank you in advance!
This method is for auth only:
firebase.auth().fetchProvidersForEmail("emailaddress#gmail.com")
This is deprecated.
firebase.auth().fetchProvidersForEmail("emailaddress#gmail.com")
Use this.
firebase.auth().fetchSignInMethodsForEmail(email)