I've come up with this library that I am using on my node.js web server as a nosql database, alternative to mongodb.
I've seen this quote:
Applications that use Google's Server SDKs should not be used in end-user environments, such as on phones or on publicly hosted websites. If you are developing a Web or Node.js application that accesses Cloud Firestore on behalf of end users, use the firebase Client SDK.
Does this mean I shouldn't use it on my node.js server express app to access the database, or it's just from the served content as web browser scripts.
If the code that uses the Admin SDK runs on the server, then that in itself doesn't introduce a risk of leaking the credentials to an untrusted environment. It of course still depends on what your code does, but there's not much we can say on that based on what you shared.
That also still leaves concern on what the code actually does. The Admin SDKs access Firebase with administrative privileges, and are not affected by any security rules you may have set on your database. So while client-side SDKs can only access data that the security rules allow, Admin SDKs can access all data - no matter the security rules.
So if you load data through the Admin SDK that you present to the user, it is up to your code to ensure you only share data that the user is authorized for.
If you are using directly to firebase from client (react, vue) use https://www.npmjs.com/package/firebase
but, if you are building api use https://firebase.google.com/docs/admin/setup/
Related
I know that if you are on a server environment, it probably makes more sense to use the firebase-admin SDK, that will grant you admin status on a trusted environment, like the one from a cloud function.
But these two packages have always gotten me confused: firebase JS SDK and firebase-admin.
See this excerpt from the firebase JS SDK
https://www.npmjs.com/package/firebase
This SDK is intended for end-user client access from environments such as the Web, mobile Web (e.g. React Native, Ionic), Node.js desktop (e.g. Electron), or IoT devices running Node.js. If you are instead interested in using a Node.js SDK which grants you admin access from a privileged environment (like a server), you should use the Firebase Admin Node.js SDK.
For a long time, I thought that the firebase JS SDK was completely incompatible with the Node.js environment of a cloud function, and that the mere presence or a simple import * as firebase from "firebase/app"; could break my function's code. But I learned today that this is not the case. Is it?
In theory, could I use the firebase package to call firebase services from the Node.js environment of a cloud function?
Other than having admin privileges, if I'm only going to do a simple task like reading a firestore document, is there a reason why I should prefer using the firebase-admin instead of the firebase JS SDK package?
You can use firebase in a Node.js environment to access certain services. However, those service calls will be made as if they were made by an end-user. Meaning all the security rules, per-user request quotas and abuse prevention mechanisms in the Firebase backend servers come into play. If your rules only allow authenticated users to access Firestore, then you will have to authenticate as an end-user in the server prior to calling Firestore. Each invocation of the cloud function will have to do this since functions do not keep state. Running that many authentication attempts from the same IP block is likely to eventually trigger some abuse prevention safeguard, and result in errors.
As a rule of thumb, use the client SDK for client-side apps, and use the server/Admin SDK for server-side applications. There are times when you might want to bend this rule. But that should be the exception as opposed to the norm, and should be done only after careful consideration.
In theory, could I use the firebase package to call firebase services from the Node.js environment of a cloud function?
The Firestore web SDK provided by Firebase was not meant for use in nodejs environments. If it happens to work, then I would consider that a bonus. But I would not expect that at all, and I would definitely not depend on that.
is there a reason why I should prefer using the firebase-admin instead of the firebase JS SDK package?
The main reason is because firebase-admin specifically supports nodejs. That's how it was meant to work. The Admin SDK is just a wrapper around the Firestore SDK provided by Google Cloud. Once you have Firestore object, it's exactly the same stuff.
As I mentioned in your other question, the SDKs might appear similar, but they are not the same. They don't have the same features and APIs.
I want to develop a "responsive mobile web application (iOS / Android)" with JavaScript to interact with Smart Contract and blockchain.
I decided to develop a hybrid mobile web application. However, the question is how to store the App Secret safe in case of developing a mobile web application with JavaScript ? Since, we do not want to store it in the mobile and blockchain because of security.
I want to develop a "responsive mobile web application (iOS / Android)" with JavaScript to interact with Smart Contract and blockchain.
Is not clear for me if you are referring to write the Mobile Application as a web site that is full responsive in mobile or if you are considering to write it using a framework like Ionic, React Native or others.
If is a responsive website than please ignore the rest of my answer once there is no secure way of securing secrets on them, as far as I am aware.
Now if is a cross platform Mobile App done with any of the many available frameworks, than keep reading because a possible solution exists to solve the problem of secrets on them.
However, the question is how to store the App Secret safe in case of developing a mobile web application with JavaScript ?
Anything running on the client side will be vulnerable to reverse engineering with tools like Xposed or Frida.
Since, we do not want to store it in the mobile and blockchain because of security.
As already pointed out by you the Mobile or Blockchain are not good places to store the App Secret.
A Possible Solution
To harden the communication between your Mobile App and the API server you should use a Mobile App Attestation service, that will guarantee at run-time that your App was not modified or is not running in a jail broken or rooted device, by using an SDK integrated in you App and a service running in the cloud.
The cloud service on successful attestation of the App integrity issues a JWT token that is signed with a secret that only the API server and the cloud service are aware and on failure the JWT token is signed with a fake secret that the API server does not know. This approach will allow for the API server to only serve requests when it can verify the signature in the JWT token and refuse them when it fails the verification.
Once the secret used by the cloud attestation service is not known by the Mobile App it is not possible to reverse engineer it at run-time, even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
On this article you can walk through example of how a Mobile App Attestation service in the cloud is used to authenticate a React Native App.
Disclaimer: I work at Approov
Xposed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo. As all changes are done in the memory, you just need to deactivate the module and reboot to get your original system back. There are many other advantages, but here is just one more: Multiple modules can do changes to the same part of the system or app. With modified APKs, you to decide for one. No way to combine them, unless the author builds multiple APKs with different combinations.
Frida
Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers.
JWT Token
Token Based Authentication
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
I'm curious about this from a general development perspective of how to secure access to online resources. We initialize our webapp with the following firebase configuration parameters:
apikey
authdomain
projectid
databaseurl
messagesenderid
How does the server use these to ensure that the requests are valid? Mainly why can't someone else just fish these parameters out of the application and then create another "Evil" application that uses the same parameters for "Evil".
"Evil" would include creating a different app with the same credentials fished up of the real app, signing up users against the same credentials contained in the real app using the plain email / password signup form, and then once the users are signed in doing even more "Evil".
Also simple node express js application and we wanted to secure access to it using the above parameters how would that work from an application request lifecycle perspective?
1) Express receives request
2) Express checks that ...
Lastly is any of this part of how openid-connect works? In other words is it following the openid-connect spec at all or is a custom based security solution built specifically for firebase?
These configuration parameters do nothing more than identify your Firebase project on the various servers. They are not in any way meant as an authentication/authorization mechanism.
See my answers here:
my answer to Is it safe to expose Firebase apiKey to the public?
and to How to restrict Firebase data modification?
and Kato's excellent answer to How to prevent other access to my firebase
You'll note that most of these point to Firebase Authentication for authenticating users, and then server-side security rules for authorizing their access. With both of these in place, it doesn't really matter anymore what code performs the access. If the user is authenticated against the same back-end, and the data access adheres to your server-side security rules, it means it follows the rules you set, no matter whose code it is.
First time I've begun using firebase with a JavaScript project:
firebaseAuth.signInWithEmailAndPassword(creds.username, creds.password
Since it is connecting to Google via websockets, will the website need to be served over HTTPS to avoid a security vulnerability?
Since Firebase Auth makes a request to Google's backend servers, it does so over HTTPS and no email/password data is unencrypted in flight. You should still strive to use HTTPS on your own system, and if you're using Firebase already Firebase Hosting offers free static web hosting with SSL provisioning on your own domain.
I'm looking for the correct, secure way to store credentials for a third party API in an Outlook add-in. This overview of the different storage options only says not to store credentials in Settings, but not where to put them, so I assumed the RoamingSettings would be okay. Then I ran into this page with information about RoamingSettings, where it says that is not the right location either.
The question then becomes: What is the right place? Should I build my own storage solution and store/encrypt the credentials in a file or cookie? That does not feel very secure either, since we are talking about what is basically a web app running in an Iframe.
I assume you cannot implement another authorization scheme (token based, cookies etc.) for your API and you are stuck with Basic Authentication and its issues. If you are using ASP.NET, with all the samples available it could be very easy to add another authentication scheme that is more adapted to web clients (such as Office web add-ins).
Having said that, for me your best option is to use HTML5 storage or cookie storage (if not implemented by browser) to store your credentials.
The fact that the app is iFramed is not really a big deal. Those storages (HTML5: sessionStorage/localStorage) rely on domains separation which means that the storage slots where you will put the credentials will not be be visible by other apps, even those living on the parent iFrame.
You may also consider the fact that you may serve the web add-ins and the apis from the same domain. They are both web applications!
You can do what Outlook itself does for its POP3/SMTP/IMAP4 passwords - use CredRead / CredWrite Windows API functions. The data can only be decrypted under the local Windows account used to encrypt the data, so it cannot be take to a different machine and decrypted.
I don't think you can access these functions from JavaScript. This is for an OWA addin, not the Outlook application, is it?