On looking at privacy for the bot I built using Microsoft Bot Framework I noticed this:
to provide the I/O service, the Bot Framework transmits your message and message content (including your ID), from the chat service you used to the bot.
I'm concerned about any messages that are sent to my bot being sent in the clear.
Has anyone considered and/or implemented encryption in order to maintain the privacy of the messages in their bot? Or does anyone have any other solution?
When you register your chatbot, it requires an https endpoint. So, your message won't be sent in the clear. Additionally, you must generate an API key and a private password key for secure access to your chatbot so that only the Bot Connector can communicate. Make sure you secure your private keys so no one else can access your chatbot.
Related
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.
We need some async workers for some 1-2 min tasks and then provide the user feedback from this tasks.
The idea would be to use the rabbitmq mqtt websocket plugin and provide the user feedback when the calculations done directly in the browser.
For our "old" stack we have some api endpoints as a layer between the user (browser) and rabbitmq services which more or less act as fire and forget.
As mentioned, we now need to provide feedback where we thought it would be create to user websockets (rabbitmq mqtt plugin).
But we are wondering how do we secure the exposed websocket endpoint for each user? Currently its not a problem as we have an amqps clients with X.509.
Our new features need has public access so we can not auth the user beforehand.
Is there a way to directly and securly use the exposed endpoint or do we need a layer in between as we have now?
The RabbitMQ Web MQTT plugin supports TLS. You can then use a username / password to authenticate the user, or use client certificates.
If you need public access then there is no way to secure the endpoint. This applies to all MQTT brokers, not just RabbitMQ.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
If you use a plugable authentication source (sorry, not familiar with what RabbitMQ offers here) e.g. that stores user/password in a database. Then you can generate a short lived set of credentials for each session and the webpage can request these from the server via a REST API and then use these to authenticate the MQTT connection over WebSockets.
This means that credentials are only exposed as variables for a short time as temporary variables in the browser, which can be revoked easily as soon as the web session/actions are complete
I have created an azure signalr service with serverless option.
The negotiate function is able to generate JWT token with 'x-ms-client-principal-name' and the connection gets established without issues.
I have referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-concept-serverless-development-config and the function is able to send events to a particular userid/groups.
I have been asked to secure the client - server communication.
I am new to security domain. I referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-tutorial-authenticate-azure-functions this link but I am not able to configure the given sample app and not able to understand the concept.
My scenario is: I have a Client .net web app in which user can login using organization account as well as using google.
This app calls azure signlar negotiate function with userID and the deviceId in which it is interested to receive events through signalR function.
Signalr function gets events from the azure eventhub trigger and sends it to the groups.
Please help me to increase the security of this application. Is the token received from negotiate function sufficient as far as security is concerned?
Can any unauthorized user connect to my azure subscribeToGroup/sendEvent functions with the acquired jwt token from negotiate?
I am trying to use this https://github.com/Azure/azure-functions-signalrservice-extension in which idToken and claimTypeList are additional parameters along with x-ms-client-principal-name(userid). But I am not able to understand this with respect to security.
The client in this sample is index.html with auth.js. But how it is said to be secure is not understandable.
Please help and direct me for the correct setup and code.
When I create a bot in Slack, I can use channel configuration on Azure Bot Service to receive event/message from Slack and communicate with my Web App Bot which handles various functions.
However, when I create a bot in a chat service which is not supported in channel configuration (e.g., Discord), I need to set up a client in my Web App Bot (e.g., Discord.Net) to communicate with the service.
Then, although I guess the Direct Line channel (REST API) will handle communication between the Web App Bot and Bot Service, but am not sure if it's correct. Is my assumption right?
Also, it is not clear for me if there's an advantage of using Bot Service in this situation, because simply I may host an individual web app on Azure or another location and let it communicate with the chat service. Why do I need to add one more service to handle?
I suppose that one possible advantage could be that I can easily access various features (e.g., LUIS) via the Bot Service. Also, the bot can handle various platform like Skype or Cortana with one code.
But still I don't really understand this topic. Could anyone give me a suggestion and best practice?
Below is my current understanding, it could be wrong though.
Directline API isn't the easiest to work with, and making a Bot Framework bot work with Discord is going to take a good amount of work. But the purpose of the Directline is to be the connection between your bot (Azure Bot Service/Web App Bot) and Discord. To use the Directline API, you're going to:
1) Get your directline secret by registering your bot on Azure (Azure Bot Services)
2) Create your directline object, using above secret (this is the line of communication between ABS and Discord)
3) Use your directline object to POST activities to the bot from the user and Listen for activities from the bot
4) Additional purposes not related to conversation: your directline object will monitor connection status of your websockets, and keep the token refreshed for the conversations
The Directline-js repo has a good README and code samples, but bear in mind that the framework is constantly being improved. As of this writing, there are 8 pull requests waiting for review for the repo.
The AI Help Website wrote a preview back in July 2018 (before the release of v4) on how to use the Directline API with C#
And finally, the official documentation for the Directline API is here
As for connecting your bot with Discord, the Discord API reference has instructions on how to get your authorization token here.
As far as I understand, the Emulator is using the DirectLine API to talk to the locally hosted bot, i.e. with http://localhost:3978/api/messages.
How is this possible? To use DirectLine API one needs to
register its bot in the BotConnector
provide the Messaging endpoint
enable DirectLine API and generate DirectLine API secret
The emulator fulfills only the messaging endpoint requirement (http://localhost:3978/api/messages) but still it works perfectly. Why do other channels require BotConnector registration?
So, based on the podcast linked in the GitHub issue provided by #Ezequiel Jadib, the emulator is emulating BotConnector services and as such can directly communicate to the locally hosted bot.
Dan Driscoll explains it would be possible to avoid DiretLine API and talk directly to the bot, though this would mean operating outside the BotFramework ecosystem and you would need your way to deal with security (and probably other things as well)