I created a Dialogflow service account and assigned it the role of Dialogflow API Client (i.e. can call all methods on sessions and conversations resources as well as their descendants). I also created a (JSON) key.
Are there any risks associated with deploying this key as part of my client?
From what I understand, the role is read-only for everything else (i.e. Basically the client can create sessions and query intentens, and that's it).
Deploying this key along with your code to a production server should be fine. However, keep in mind that you should NOT add this file to your Github / Bitbucket repository. Yes, this is read-only but someone could, in theory, spam your Dialogflow agent which would result in you reaching your Dialogflow API quota.
Hope this helps.
Related
Summary
I need to create an application where the user will subscribe to a plan that will give him a consumption of requests to the backend.
Backend: I will use nodejs and express to create the backend
Frontend: I will use reactjs to create the frontend. I will create the admin panel for user control you account.
Detail
I need to create a plugin for Wordpress that will consume these requests from the user's account. As I've never worked with this type of structure, I don't know how to guarantee that these plugins are the client's own and not someone who took his credentials and is spending his plan.
I took a look at RSA encrypt to make a data signature, but I still don't understand the best way to create this application.
I also saw about JWT but the plugin in wordpress would not have the account credentials to use JWT as login, and usually plugins and REST API using public key and secret key or api key.
Another use would be embedding a form on another site or using the REST API.
I'm building a bot hosted on Azure and using firebase for cloud functions (ie proactive messaging, collating data etc.) and for cloud firestore db.
Sorry as I'm a bit new to security and please feel free to just link to any useful resources on the below.
Within my bot code I'm using the admin SDK to access firebase. The bot will have no created users. Firestore rules therefore block read and write access to everyone (as admin SDK still has full access).
I have a couple of questions about security:
Is using the admin SDK in this manner (on the bot side) fine? It looks a bit mixed on the firebase documentation - ie https://firebase.googleblog.com/2019/03/firebase-security-rules-admin-sdk-tips.html mentions only using these in trusted environments, which I think the bot should be?
Secondly I am trying to send messages from cloud functions to the bot itself. This will just be a post with no sensitive data attached but I would like to authenticate this on the bot side to check it is from the backend. Is there a way to use firebase to do this (ie authenticating on client?). How else can I do this? I've been a bit confused reading about JWTs and encoding etc.
Thanks
Is using the admin SDK in this manner (on the bot side) fine?
It's totally fine. You don't have security rules there but Cloud functions (or servers) are secure environments so no one can reverse engineer that. You should validate the incoming data yourself. If I assume you are using Discord.JS, then you can just read ID of author and authorize the user:
const {id} = message.author
// use this ID as an identifier
You don't have to worry about the ID being false as it's not being passed by any client. Just make sure you fetch resources of that specific user only.
I am trying to send messages from cloud functions to the bot itself. I would like to authenticate this on the bot side to check it is from the backend
You don't need to validate that. Anyone can send message through your bot only if they get your bot's token which is a secret on server/cloud function. You must make sure only you have it.
I'm seeking your advice to piece together a mechanism that would facilitate authentication to Dialogflow ES and CX to allow running experiments on multiple agents (projects) from our workbench application in a smooth and error-proof manner. The workbench is an internal tool written in TypeScript (using the dialogflow RPC node module) running outside of GCP. Our users analyze the results of sending the same inputs (utterances) to multiple agents, usually going back and forth between them in the course of their work.
With proper IAM configuration, we have been able to detect intents successfully by doing a gcloud auth application-default login, however we haven't found a way to update the quota project programmatically or to specify the quota project through the google.cloud.dialogflow library, so we haven't been able to fix the "switch easily between projects" part. It looks like tampering with the quota_project_id property in application_default_credentials.json once authenticated is the way to go (gcloud auth application-default set-quota-project <project>) but we would have preferred doing this programmatically.
Using service account keys (JSON) works as expected and that's what we have been doing so far, that's also what we do in our CI/CD pipeline and in our agents running in production. But we aim at reducing the amount of service account credentials file that we share with individuals. Ideally, speech/data scientists would use their own end-user credentials to perform experiments.
We are looking for alternatives so that users would authenticate once with gcloud auth application-default login and the workbench would handle the rest behind the scenes, using only, as additional argument, the project-id against which the experiment must be run. This would eliminate the need to pause the experiment to update the quota project (using set-quota-project), or to update the GOOGLE_APPLICATION_CREDENTIALS variable when using service account keys.
Another thing we tried was Service Account Impersonation, unfortunately this does not seem supported by the google.cloud.dialogflow library, so even though we were able to successfully submit requests (with Curl/Postman) to the Dialogflow RESTful API using impersonation, we haven’t been able to leverage this mechanism in our code.
Has anyone been able to overcome a similar challenge? Is there any other authentication mechanism that could help us achieve this goal?
if anyone could give me a clear high level answer that would be great. I want to integrate a payment gateway into my app eg: Strip/Braintree, and I have gotten it all working to the testing part but now I am wondering for me to move it to production do I need to host the back end server for retrieving the tokens myself?
Currently I hosted the test server locally to test that it works. But what now? Do I need to host this on a server for all time so my app can get its tokens?
Please help.
Yes, you have to.
You can start with a Virtual Machine at DigitalOcean or Vultr. Replicate your test environment there, then harden the server, etc.
If you're new to that then I recommend you to find someone who has experience setting up servers in production environments.
Thanks for your help. I spoke with Stripe and below was there response. They confirmed that you do need a server backend all the time.
--
Unfortunately, we don’t provide any hosted solutions when working with app based payment flows—you would need to have a back-end setup in place or use a serverless solution such as Heroku, both for your eventual move to a production environment and also while in development to test your back-end.
Generally speaking, you’ll use our SDKs when building your app to implement our client-side framework enabling you to securely collect and tokenize payment details from customers from within your app. However, the back-end server is where you’ll actually make requests to Stripe when you need to create a charge, refund a payment or take some other API related action.
Additionally, your back-end server will play a critical role as that’s where you’ll need to generate the ephemeral keys that will be used as the client-side session credentials for the app’s user. The use of ephemeral keys will facilitate the retrieval and updating of customer objects in Stripe for a given user (the persistent creation and use of individual customer objects is a default behavior for our mobile SDKs), but will ensure that your Stripe account’s secret API keys remain protected (public API keys are still used in the client).
Firebase provides database back-end so that developers can focus on the client side code.
So if someone takes my firebase uri (for example, https://firebaseinstance.firebaseio.com) then develop on it locally.
Then, would they be able to create another app off my Firebase instance, signup and authenticate themselves to read all data of my Firebase app?
#Frank van Puffelen,
You mentioned the phishing attack. There actually is a way to secure for that.
If you login to your googleAPIs API Manager console, you have an option to lock down which HTTP referrer your app will accept request from.
visit https://console.developers.google.com/apis
Go to your firebase project
Go to credentials
Under API keys, select the Browser key associated with your firebase project (should have the same key as the API key you use to initialize your firebase app.)
Under "Accept requests from these HTTP referrers (web sites), simply add the URL of your app.
This should only allow the whitelisted domain to use your app.
This is also described here in the firebase launch-checklist here: https://firebase.google.com/support/guides/launch-checklist
Perhaps the firebase documentation could make this more visible or automatically lock down the domain by default and require users to allow access?
The fact that someone knows your URL is not a security risk.
For example: I have no problem telling you that my bank hosts its web site at bankofamerica.com and it speaks the HTTP protocol there. Unless you also know the credentials I use to access that site, knowing the URL doesn't do you any good.
To secure your data, your database should be protected with:
validation rules that ensure all data adheres to a structure that you want
authorization rules to ensure that each bit of data can only be read and modified by the authorized users
This is all covered in the Firebase documentation on Security & Rules, which I highly recommend.
With these security rules in place, the only way somebody else's app can access the data in your database is if they copy the functionality of your application, have the users sign in to their app instead of yours and sign in/read from/write to your database; essentially a phishing attack. In that case there is no security problem in the database, although it's probably time to get some authorities involved.
Update May 2021: Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security described above, so that you have another shield against abusive users that do use your app.
By combining App Check with security rules you have both broad protection against abuse, and fine gained control over what data each user can access.
Regarding the Auth white-listing for mobile apps, where the domain name is not applicable, Firebase has
SHA1 fingerprint for Android apps and
App Store ID and Bundle ID and Team ID (if necessary) for your iOS apps
which you will have to configure in the Firebase console.
With this protection, since validation is not just if someone has a valid API key, Auth domain, etc, but also, is it coming from our authorized apps and domain name/HTTP referrer in case of Web.
That said, we don't have to worry if these API keys and other connection params are exposed to others.
For more info, https://firebase.google.com/support/guides/launch-checklist