Stealing Downloads from Slack Users | Hacker News Reader

Stealing Downloads from Slack Users

medium.com

107 pointssoheilpro12 comments

I've always found Slack's link handling to be weird and annoying. Show me the URL I'm going to be sent to, and stop clickjacking. Please. My company has an internal domain, so when we link to internal docs, it splats because Slack can't resolve the hostname. And we're paying for this inconvenience.

I'd be interested to hear how Slack patched this. Hopefully by removing the ability to apply settings from URLs altogether, rather than attempting any sort of sanitisation on the download settings.

It intrigues me that (per the screenshot in the post) slack appears to bundle uncompiled TS source in their app. You'd think that they'd just have a single JS bundle so their code wasn't so easy to reverse engineer.

It's a JS client side application, it really doesn't make that much of a difference..

> so their code wasn't so easy to reverse engineer

As a bit of history, most of our team is made up by old-school desktop engineers with a background in native desktop development (and we still have a pretty decent amount of C++ and ObjC running in our app). Decompilers these days are pretty impressive – seeing the implementation of most desktop apps is fairly trivial.

This is just a personal statement, but I never had trouble with the files being there. They're currently present to support some outdated and soon-to-be-replaced module resolution, but I'd give this advice: If you're shipping logic to users, make your peace with the fact that it can be reverse-engineered. Sure, opening a source file is a bit easier than having DotPeek decompile your DLL, but it's pretty easy either way.

In other words: My stuff should be safe and secure whether or not an attacker knows how I implemented my logic.

Modern swift, c++ and java/.net/electron/old objc are a completely different ballgame.

Sure everything can be reverse engineered, but the last 4 are so much simpler to RE. This is like saying all normal doors can be easily keybumped, so let's just leave the doors away.

Seems like two separate issues mentioned here. The second part of having an attachment with title & title_link is tricky - it might not necessarily be considered an issue. In the browser you'd be able to hover over the link and see what the actual link is going to be. If the electron app also did the same, then perhaps you'd be okay.

Perhaps the whole title/tite_link attachment styling feature should be webpage only, and disabled for the electron app.

I am having a same situation here but I am not sure whether it is the same issue or not. I have sended a file over slack but it is not downloading even I am having an error message that it is harmful. Hows that possible?

I wonder what the bounty payout for this would have been.

Not sure what this one would pay, but one of my employees found and reported a security vulnerability with Slack APIs tokens a few years ago and got a $2,500 reward for disclosing it properly.

https://hackerone.com/slack/hacktivity

Not sure if this one in on the list yet, but you can still get an idea.

From what I've seen so far in the news (about bounty payouts for solving these type of issues)

It's usually not high as you think its gonna be

Reply on news.ycombinator.com