Comment sécuriser vos webhooks pour les plateformes de chat (Workplace, Slack, Teams…)
Lorsqu’on est éditeur d’un service web, mettre en place un chatbot sur des plateformes chat telles que Microsoft Teams, Slack ou encore Meta Messenger/Workplace est un bon levier de promotion et d’adoption. D’autant que les fournisseurs de ces plateformes font tout pour faciliter le branchement à leurs espaces de conversation.
Mais si en quelques clics et une dizaine de lignes de code vous pouvez avoir votre chatbot prêt pour le service, sécuriser complètement le transfert d’information entre votre serveur et la plateforme de chat de votre choix nécessitera un peu plus d’effort 🏋️♂️. C’est ce que je vous propose de voir dans cet article.
-
Laurent Betti
- le 18 octobre 2022
Pourquoi sécuriser vos webhooks sollicités par vos bots et/ou intégrations sur des plateformes de chat tierces ?
Tout d’abord, petite présentation rapide des échanges qui peuvent avoir lieu entre votre serveur et le service de chat (pour l’exemple, prenons Meta Messenger).
L’utilisateur envoie un message à votre bot Messenger (via le site ou l’appli mobile dédiée de Meta) :
➡️ Messenger transmet le message saisi par l’utilisateur à votre serveur, sollicitant le “webhook” que vous avez spécifié (lors de la configuration de votre bot Messenger).
⬅️ Votre serveur traite le message et génère une réponse appropriée (et peut être, en parallèle déclenche une tâche automatisée, comme savent si bien le faire les chatbots Vizir 😉) qu’il transmet en retour à Workplace pour qu’elle soit finalement présentée à l’utilisateur.
Pour la seconde étape, vous n’avez pas le choix : votre requête à destination de la plateforme de chat DOIT être sécurisée, en l’accompagnant d’un “token d’accès” (fourni lors de la configuration), qui permet à la plateforme de savoir que c’est bien vous qui la contactez et pas un usurpateur. Si vous n’incluez pas ce token dans votre requête, vous recevrez un message d’erreur ✋.
Mais pour la première étape, rien ne vous contraint à vérifier que c’est bien le service de chat qui contacte votre serveur. En effet, lors de la mise en place de votre bot Workplace ou Slack (ou autre), vous avez indiqué l’URL du webhook vers laquelle devait être transmis les messages de vos utilisateurs. Vous avez également écrit la logique de ce webhook afin que votre serveur réagisse de manière approprié lorsqu’il est contacté sur cette URL. Et c’est tout ce qu’exige la configuration minimale permettant d’avoir un bot fonctionnel sur la plupart des plateformes dédiées.
Mais en l’état ce “webhook” peut être sollicité non seulement par la plateforme de chat, mais également par n’importe quelle personne qui en connaîtrait ou en découvrirait l’URL 🕵️.
Les risques encourus sont : dans le meilleur des cas, un individu mal intentionné peut envoyer une multitude de requêtes simultanées que votre serveur va essayer de traiter, perdant ainsi de la disponibilité pour traiter les requêtes légitimes. Cette sur-sollicitation, si elle est intense et s’étend sur une période relativement longue, peut mettre votre serveur K.O.
Et dans le pire des cas, si l’individu malveillant arrive à “forger” une requête que votre serveur comprend, vos données clients peuvent être altérées, supprimées ou exposées. Sympa comme perspective, hein ? 😈
Comment s’assurer que la requête provient bien de l’émetteur légitime ? La validation de la charge utile, bien sûr ! (cas pratique avec un bot Workplace)
La méthode utilisée pour garantir la provenance de la requête se nomme “Validation de la charge utile” (la charge utile étant en fait les données accompagnant la requête destinée à votre webhook).
Celle-ci nécessite que l’émetteur de la requête lui adjoigne une signature numérique générée grâce à la combinaison du contenu de la “charge utile” ainsi que d’une clé secrète qui vous aura été préalablement communiquée, à vous, le récepteur de la requête. En quelques lignes de code vous allez pouvoir vérifier si les données des requêtes reçues par votre webhook ont bien été signées avec la clé secrète.
La méthode présentée ici s’applique indifféremment à toutes les plateformes de chat. Ce qui peut varier d’un fournisseur à l’autre, c’est l’algorithme à utiliser pour vérifier la requête ainsi que la clé secrète à utiliser.
Toujours dans le cas de Workplace/Messenger, savoir exactement où aller chercher la clé secrète vous fera gagner un temps précieux. Il s’agit de l’App Secret de votre intégration (et non pas le “token d’accès”) que vous pouvez trouver dans le panneau de configuration de cette dernière :
Ensuite il vous faut légèrement modifier la configuration de votre serveur (ici on utilise NodeJS avec Express) pour que les données brutes soient attachées à l’objet “request” :
Et enfin vous pouvez ajouter le code de vérification au contrôleur de votre webhook. Ou mieux, isoler ce code dans une fonction utilitaire dédiée, comme ici :
Et voilà, avec ces quelques lignes, vous êtes certains de ne traiter que les requêtes légitimes 👌.
Bonus : Certaines plateformes vous permettent même d’aller un cran plus loin en vérifiant que le timestamp de la requête correspond à un horaire suffisamment proche et ce afin d’éviter les “attaques par rejeu”. C’est notamment le cas de Slack.
🍔 Menu
Pour tout savoir sur les chatbots et l'IA, inscrivez-vous à la Newsletter
Pas les ressources ? On s’occupe de tout
Bien évidemment, si vous n’avez pas le temps ou les ressources pour vous occupez de ce type de détails techniques en interne, Vizir peut s’en occuper pour vous. N’hésitez pas à réserver un rendez-vous de découverte avec notre équipe pour en discuter !
