Re:Slack Is Buying HipChat from Atlassian
by AntonyGarand on Thursday July 26, 2018 @10:29PM
(#17623035)
To be fair, there are tons of very low severity vulnerabilities disclosed on HackerOne and this does not mean the application is vulnerable. Slack is definetly not vulnerable because it is written in php and you can pollute an iframe on their career website.
Having such a program in place is actually good for the application security as it does get audited by tons of hackers thanks to the monetary rewards.
I agree it's theoretically possible to write a secure project in PHP, but it's very difficult, especially if you're hiring people like crazy.
If you divide the amount they've paid out in bounties by the number of bounties paid, and compare with their bounty tier rules, it's clear that a lot of the vulnerabilities that were reported in Slack are relatively severe.
(And I agree bug bounty programs are great; we also use HackerOne)
If you use a framework like Laravel it probably covers most things.
You could easily write a massively insecure application in core python, but things like Zulip use Django which shields you from most of it.
It is not about the language is it... I don't think there is so big difference between php and python. Besides Slack is most probably using whole lot more tech than php.
It is about Zullip being open source.
It's also about the language. See, for example,
https://www.quora.com/Why-is-PHP-hated-by-so-many-developers
The writing's been on the wall for HipChat for a long time; e.g. the user experience has been stagnant for many years (e.g. they never added emoji reactions). And even back in 2013, every HipChat customer I've encountered was unhappy or at best unenthusiastic about the product. So we've seen plenty of folks migrate from HipChat to Zulip.
I expect most enterprises will end up on one of the open source Slack alternatives (Zulip, Mattermost, Rocket.Chat, etc.). Frankly, they should have been using one of them anyway. If you care about a really high level of security, you want to be using well-maintained open source software. The well-maintained part is obvious, but the open source piece is really important too: It's a lot easier for white-hat hackers to find and report security bugs in software with access to the source code, and so there will be fewer that haven't been found and fixed yet.
You certainly don't want to be using a PHP app that's had over 700 confirmed security bugs found by external people (https://hackerone.com/slack) -- you can be pretty sure there are more being introduced every week.
I'll add that I expect to see more proprietary on-premise products that are the stepchild of a SaaS product disappearing over the coming years. It's a lot harder to ship software for the on-premise use case, especially if you have engineering culture used to just shipping for a single installation in the cloud (which almost everyone who works on proprietary software is). If you have the right processes and toolchain, it doesn't have to slow you down (and I don't feel it does for Zulip, with our amazing developer tooling and 98% backend test coverage), but very few organizations succeed at this. I've certainly heard some incredible horror stories from famous Silicon Valley companies about teams of engineers spending months on making a fork of a SaaS product shippable for each on-premise release.