Security concerns regarding video rendering on link unfurl about python-slack-sdk

[WilliamBergamin]

Hi @saurabh0719 thanks for writing in 💯

This question seems to target the behavior of the backend, and does not strictly affect the python-slack-sdk project, I will try to get some answers from my end but you can also join our slack community to ask about this behavior

[saurabh0719]

@WilliamBergamin thanks for the quick turnaround. Yeah it does not affect the python SDK per say, we just happen to use the python SDK ourselves and I've had a great experience asking questions here as I always seem to get a quick reply and clarification! So since this was time sensitive I figured, why not.

I'll surely check out the community, but if you do have anything that you can share from your end, then please do. :)

[saurabh0719]

https://forums.slackcommunity.com/s/ seems to be down at the moment. Unsure where to post this question. Will an email to slack support work? But I figured that's not for developer problems.

@seratch will you be able to help by any chance?

[seratch]

@saurabh0719 I may not be able to resolve all your questions / concerns on security but let me share a few general points:

is there any guarantee on the security of these URLs as we strictly DO NOT want it to fall in the hands of any user or anybody outside the workspace and we're expecting it to be used by slack ONLY

As long as you have the necessity to make the video URL available in a video block, the URL must be publicly accessible for everyone including Slack's servers. Unfortunately, there is no greatly secure way to limit the visitors to the URL. If you attach a long-enough query string to the URL, the URL should be almost inaccessible to people outside the Slack workspace. With that being said, if the URL is leaked, still there is a possibility that random people may access the video.

We use signed URLs with a timeout for our video content, as most other applications, and I wanted to confirm if slack makes a request for this video content each time the message block comes into frame/the chat is loaded/etc.

When you display the video URL only on a short-lived modal view, a URL with expiration can work well. However, when it comes to channel messages, the URL needs to be the same forever (as long as your app does not periodically update all the URLs it posted in channels). Thus, this approach does not help. Also, I cannot think of any other workaround in this direction.

3. Is there any way to identify requests coming from slack?

Unfortunately, there is no way to achieve this as for incoming requests from Slack.

Our platform team does not have any short-term plans to enhance the video block element to support your use cases. Therefore, the only meaningful suggestion I have is to give up embedding the video content in Block Kit using the video block element. Alternatively, you can upload the video to your Slack workspace and/or just share the video content URL as a link in Slack.

I understand that this is not the best expected answer for you, but I hope this clarifies.

[WilliamBergamin]

@saurabh0719 I've been querying internally to get this information and agree with everything @seratch has mentioned

I can also answer the following

2. Does slack download the content ahead of time and keep a copy?

No slack does not make a copy or cache the content

We use signed URLs with a timeout for our video content, as most other applications, and I wanted to confirm if slack makes a request for this video content each time the message block comes into frame/the chat is loaded/etc.

I have some context for Mobil specifically on the client/browser this may be slightly different, Mobile loads the video only when playing it in a modal, not on the chat surface directly. The modal uses standard HTTP caching, the same as if the URL of the video was copy pasted into the navigation bar on Safari iOS, or Chrome Android.

I may be getting more info on this in the coming days, I will share what I can here

[github-actions]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[github-actions]

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.