06-19-2020 02:09 PM
It appears to me that there is no real security in Incoming Webhooks. I'd like to use it to send some alert messages from Azure/OpenShift etc. but it seems like the 'security' it uses is just a long hard to guess URL. There's no authentication per say. Is there any info I could use to get this past me security teams? Any math even on how hard it is to guess that URL path ?! :)
06-20-2020 10:30 AM
Hi
It depends on the url - with https its as safe as browsing any https site
06-22-2020 02:22 AM
I don't agree with that statement. You are not browsing but enacting some potential action based on posting to that incoming WebHook. I have seen other WebHooks that require something in the payload for auth. Perhaps I should use the API to post messages.
06-22-2020 07:17 AM
I think your understanding is pretty accurate. Certainly using the full REST API is preferable from a security standpoint, where the secret is not present in the URL/params. Use of incoming webhooks is going to trade some safety for convenience when you just need a quick and dirty chat-ops notification...
06-22-2020 01:54 PM
I guess so. Not sure my sec guys will go for this. I guess it's about showing that worst case is a DDOS or a flood of messages to a space.
03-27-2023 11:00 PM - edited 04-03-2023 11:24 PM
You are correct that the security of Cisco Incoming Webhooks relies primarily on the secrecy of the webhook URL. However, there are ways to improve the security of your webhook integration.
One way to increase the security of your webhook is to use HTTPS to encrypt the communication between the sender and the webhook. This ensures that the webhook URL and any data transmitted over the network are protected from eavesdropping and interception.
Another way to enhance the security of your webhook is to implement message validation using message signatures. This ensures that the incoming messages are from trusted sources and have not been tampered with during transmission. To use message signatures, you would need to generate a shared secret key and use it to sign outgoing messages. The recipient of the message would then use the same shared secret key to validate the signature and ensure the message's authenticity.
Regarding the security of the webhook URL, it's challenging to quantify the exact difficulty of guessing the URL path without knowing the specific implementation details. However, the webhook URL should be kept confidential and only shared with trusted sources. Additionally, you can use rate limiting and IP address filtering to prevent abuse and limit access to your webhook.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide