I need some advice on how to properly set up a solid security structure for my app.
What my app does
The goal of this app is to provide a data aggregation service.
To do this, the user needs to provide login data for a variety of his accounts.
The user can then trigger a firebase cloud function which performs web scraping with the provided credentials, encrypts the result-data, and stores it to firestore.
Current encryption
Currently, the encryption key is stored in a separate document in the firestore database.
The cloud function gets the key, performs de- and encryption, and stores the data as a cipher.
Now I know this is kind of pointless because if someone would hack my Google account, the data would still be readable for him.
Problems
Besides this security flaw, I am facing some other problems.
As long as the described encryption only happens in a cloud function, this may be relatively secure because the cloud functions are isolated. My problem is, that there is no way to perform a database query from the client because:
there is no "onRead" cloud function, in which I would decrypt the data before sending it to the client
decrypting the data on the client would expose the encryption key to potential hackers (at least that's what I am thinking at the moment)
Conclusion
I have decided to try GCP's KMS which seems to be the solution to all of these problems. However, I am overwhelmed by all these new terms and most of the resources I found seemed outdated.
Closest I came was this post: http://www.geero.net/2017/05/how-to-encrypt-a-google-firebase-realtime-database/ but since it's from 2017, it seems to be outdated (As far as I understand from this answer)
So I am a bit lost on where to start, what to use, and how to manage responsibilities.
Questions
Is it possible to create a secure client-sided decryption with KMS? If
not, how should this get handled?
How do I implement KMS with firebase and firebase cloud functions? (Any pointing in the right
direction would help)
Do you recommend using this package for the cloud function
implementation: https://www.npmjs.com/package/#google-cloud/kms
Did you spot and other security flaws than those I mentioned?
Do you have any additional advice?
Thanks in advance!
I manage a website which uses Firebase Authentication with email and password to login.
I want to do some brute force attack protection. However it is not important for me which exact mechanism is used. However it's important that is it easy to implement and maintain. Also our users are not especially tech savy, so I am trying to avoid 2FA.
It could for example be a mechanism which forced the user to verify their email after three failed login attempts.
Therefore I was hoping to find some help in the docs. However I could not find any easy to use built in mechanism. Most answers mention that you could contact support if you see mysterious traffic. There is also specific advise for specific kinds of attacks.
Can anybody provide an example to a simple, effective, and easy to implement mechanism guarding against brute force attacks?
As far as I understand, my Google Cloud Functions are globally accessible. If I want to control access to them, I need to implement authorization as a part of the function itself. Say, I could use Bearer token based approach. This would protect the resources behind this function from unauthorized access.
However, since the function is available globally, it can still be DDoS-ed by a bad guy. If the attack is not as strong as Google's defence, my function/service may still be responsive. This is good. However, I don't want to pay for those function calls made by the party I didn't authorize to access the function. (Since the billing is per number of function invocations). That's why it's important for me to know whether Google Cloud Functions detect DDoS attacks and enable counter-measures before I'm being responsible for charges.
I think the question about DDOS protection has been sufficiently answered. Unfortunately the reality is that, DDOS protection or no, it's easy to rack up a lot of charges. I racked up about $30 in charges in 20 minutes and DDOS protection was nowhere in sight. We're still left with "I don't want to pay for those function calls made by the party I didn't authorize to access the function."
So let's talk about realistic mitigation strategies. Google doesn't give you a way to put a hard limit on your spending, but there are various things you can do.
Limit the maximum instances a function can have
When editing your function, you can specify the maximum number of simultaneous instances that it can spawn. Set it to something your users are unlikely to hit, but that won't immediately break the bank if an attacker does. Then...
Set a budget alert
You can create budgets and set alerts in the Billing section of the cloud console. But these alerts come hours late and you might be sleeping or something so don't depend on this too much.
Obfuscate your function names
This is only relevant if your functions are only privately accessed. You can give your functions obfuscated names (maybe hashed) that attackers are unlikely to be able to guess. If your functions are not privately accessed maybe you can...
Set up a Compute Engine instance to act as a relay between users and your cloud functions
Compute instances are fixed-price. Attackers can slow them down but can't make them break your wallet. You can set up rate limiting on the compute instance. Users won't know your obfuscated cloud function names, only the relay will, so no one can attack your cloud functions directly unless they can guess your function names.
Have your cloud functions shut off billing if they get called too much
Every time your function gets called, you can have it increment a counter in Firebase or in a Cloud Storage object. If this counter gets too high, your functions can automatically disable billing to your project.
Google provides an example for how a cloud function can disable billing to a project: https://cloud.google.com/billing/docs/how-to/notify#cap_disable_billing_to_stop_usage
In the example, it disables billing in response to a pub/sub from billing. However the price in these pub/subs is hours behind, so this seems like a poor strategy. Having a counter somewhere would be more effective.
I have sent an email to google-cloud support, regarding cloud functions and whether they were protected against DDoS attacks. I have received this answer from the engineering team (as of 4th of April 2018):
Cloud Functions sits behind the Google Front End which mitigates and absorbs many Layer 4 and below attacks, such as SYN floods, IP fragment floods, port exhaustion, etc.
I have been asking myself the same question recently and stumbled upon this information. To shortly answer your question: Google does still not auto-protect your GCF from massive DDOS-attacks, hence: unless the Google infrastructure crashes from the attack attempts, you will have to pay for all traffic and computing time caused by the attack.
There is certain mechanisms, that you should take a closer look at as I am not sure, whether each of them also applies to GCF:
https://cloud.google.com/files/GCPDDoSprotection-04122016.pdf
https://projectshield.withgoogle.com/public/
UPDATE JULY 2020: There seems to be a dedicated Google service addressing this issue, which is called Google Cloud Armor (Link to Google) as pointed out by morozko.
This is from my own, real-life, experience: THEY DON'T. You have to employ your own combo of rules, origin-detection, etc to protect against this. I've recently been a victim of DDoS and had to take the services down for a while to implement my own security wall.
from reading the docs at https://cloud.google.com/functions/quotas and https://cloud.google.com/functions/pricing it doesn't seem that there's any abuse protection for HTTP functions. you should distinguish between a DDoS attack that will make Google's servers unresponsive and an abuse that some attacker knows the URL of your HTTP function and invokes it millions of times, which in the latter case is only about how much you pay.
DDoS attacks can be mitigated by the Google Cloud Armour which is in the beta stage at the moment
See also related Google insider's short example with GC Security Rules and the corresponding reference docs
I am relatively new to this world, but from my little experience and after some research, it's possible to benefit from Cloudflare's DDOS protection on a function's http endpoint by using rewrites in your firebase.json config file.
In a typical Firebase project, here's how I do this :
Add cloud functions and hosting to the project
Add a custom domain (with Cloudflare DNSs) to the hosting
Add the proper rewrites to your firebase.json
"hosting": {
// ...
// Directs all requests from the page `/bigben` to execute the `bigben` function
"rewrites": [ {
"source": "/bigben",
"function": "bigben",
"region": "us-central1"
} ]
}
Now, the job is on Cloudflare's side
One possible solution could be the API Gateway, where you can use firebase authentication. After successful authentication to the api gw it can call your function that deployed with --no-allow-unauthenticated flag.
However I'm confused if you are charged for unauthenticated requests to api gw too..
I was not able to find any resources about this, hence wanted to ask if it is a good idea / necessary to add throttling to callable https cloud functions in firebase on per user basis?
Example, I want to limit one user to be only able to call https function every 5 seconds.
If it is a viable thing to do, how would it be acheived?
There is not any inbuilt per user throttling capabilities in cloud functions. You have a few options of doing your own:
Put logic in your client side apps that tracks the amount of times a user is calling them and deny the call if too frequent
Issue here is that if someone is trying to game you this wouldn't be 100% effective as they could use multiple windows, etc.
You could implement a database solution where you track their usage and at the beginning of your function you check if they are violating your rate limit
Issue here is you are still having the triggers of your functions incurring the costs.
If it was a super big issue for you, I would recommend looking at using an API management platform such as Apigee where you can apply policies such as rate limiting
This a heavy weight solution with an increased cost and so wouldn't do it unless necessary
I'm looking for the best reusable libraries and inbuilt features in ASP.Net to prevent the OWASP top 10 security vulnerabilities like injection, XSS, CSRF etc., and also easy to use tools for detecting these vulnerabilities for use by the testing team.
When do you think is the best time to start incorporating the security coding into the application during the development life cycle?
My two cents:
Never ever trust user input. This include forms, cookies, parameters, requests...
Keep your libraries updated. Everyday security flaws arise among us. Patches are released, but they are worthless if you don't apply them / upgrade your libraries.
Be restrictive and paranoid. If you need the user to write his name, be restrictive and let him only use [A-z] characters and so on. Strong constraints will annoy the average user, but it will make your system more secure.
Never log critical data. This means that you should not log things such as what password a user used (obvious) but also you should not be tempted to log what password did a user typed when he failed to log in into the system (because he may had a typo easy to guess). You can extend this example to all critical data. Remember, if it's not there, you don't have to worry about someone trying to get it.
And extracted from wikipedia's CSFR article:
Requiring authentication in GET and POST parameters, not only cookies;
Checking the HTTP Referer header;
Ensuring there's no crossdomain.xml file granting unintended access to
Flash movies[14]
Limiting the lifetime of authentication cookies
When processing a POST, disregard URL parameters if you know they should
come from a form
Requiring a secret, user-specific token in all form submissions and
side-effect URLs prevents CSRF; the
attacker's site can't put the right
token in its submissions
My experience is that just giving the developers a toolbox and hoping for the best doesn't actually work all that well. Security is an aspect of code quality. Security issues are bugs. Like all bugs, even developers that know better will end up writing them anyway. The only way to solve that is to have a process in place to catch the bugs.
Think about what sort of security process you need. Automated testing only? Code review? Manual black-box testing? Design document review? How will you classify security issues in your bug tracking system? How will you determine priority to fix security bugs? What sort of guarantees will you be able to give to customers?
Something that may help you get started is the OWASP ASVS verification standard, which helps you verify that your security verification process actually works: http://code.google.com/p/owasp-asvs/wiki/ASVS
First best practice: Be aware of the vulnerabilities while coding. If you code think about what your are doing.