A policy of so-called responsible disclosure is a reasonable approach to take when dealing with an established product/service that contains a minor vulnerability, something potentially dangerous but unlikely to be exploited in the immediate future with serious negative effects.
In this case, we appear to have a new project run by people who don't know what they're doing, with a glaring vulnerability that had presumably already compromised 80+ people's sensitive credentials and in turn who knows what other sensitive information. Bringing it down as fast as humanly possible and loudly so no-one else gets damaged in the meantime is entirely justified in a case like this.
In his own responses, he says that he won't email the users! I can't imagine how upset I would be if this had my information. Access control for something like this is dead simple
If they're based almost anywhere in the US or EU, they might well have a legal obligation to notify at this point.
(I am not your lawyer, etc.)
In this case I think the public disclosure would have two effects: 1. Put current users of the product at risk. 2. Prevent people from signing up for the product.
So the question really becomes, does 1 outweigh 2, or vice-versa? (and the answer to that also depends on how cooperative & quick the company will be with a fix)
With responsible disclosure, only the original poster and anyone else who happened to figure this out would know. Now everyone does, and any random attacker can just go to the site and harvest AWS credentials from anyone signed up.
In a position where no choice of action/inaction is guaranteed to be harmless, I think limiting the damage is probably the most practical choice, and certainly a reasonable one. It limits the number of potential victims, and it also serves as a warning to those developing future sites that this sort of screw-up is not acceptable.
I believe this was one of those cases. The founders of this application were told in the original thread that there were security issues. They didn't respond to the issue and continued allowing users to signup.
Their immediate response should have been to shut down the application with a maintenance page. Their response was instead to tell users to delete their accounts[1].
The other factor here is that because of the type of application users were likely to upload private and sensitive information. This wasn't a simple todo application where users would test it out with fake data, it is a backup application.
The combination of poor initial response, the sensitivity of the data being used and the popularity of the application (being at the top of HN, all over twitter etc.) would lead me to make the exact decision what this blogger did. It was important to notify all users asap that there are problems here, so that they could act on it.
Edit: didn't you do something similar with the Diaspora launch? I think that was another example where it was important to get the vulnerability information out since that first release was popular, users were uploading sensitive information and it was going to take some work to secure the app.
FTR, I don't think that the gap between saying there is a security vulnerability and describing it is very large, especially when the audience contains capable penetration testers.
1) The founder's behavior in the other thread, including refusing to notify affected parties.
2) Such a simple mistake worries me about what else might be vulnerable in the application which is built to handle users' backup data, and for that reason alone, I think this article is extremely important right now.
Since whomever discovered the bug was able to access others' sensitive information, they have to disclose.
I know it's hard for people behind this company and they probably invested a lot of time and love to build this product. But we can't just let that pass, for the sake of people that'll use that service next (I mean, with something that basic missed, what next ?).
Please, just get back to learn creating web applications, and see you in a few months for a great product ! (because, yes, the idea was interesting)
Don't trust the client.
The user ID in the URL like this is a giant "try editing me and see what happens" sign, even if you came with no intention of providing unsolicited pen testing. I seriously doubt just this one person noticed.
What's really surprising is that apparently the dev on this never viewed any porn on the internet.
It's a problem of competing claims -- you want to keep the world safe so end users are protected, and are willing to use new (secure) services, but you also want to avoid discouraging developers (either these guys, or others who see how they're being ragged on and choose not to develop something on their own).
It's not a fundamental flaw in the application, just an admin interface error. Yes, they should have known to test, but I reserve the nuclear hate for willfulness, since hate and vitriol is sometimes in short supply.
Just yesterday we had someone publish a "securely delete your email" application. 'tptacek found problems in it immediately[1], but he didn't call the guy incompetent or an idiot or "never trust anything he does again." There was no attempt to shame.
I see the more experienced people around here have a lot more sympathy for these guys. If you've done a lot, you've also had some public mistakes. You grow empathy.
I do find the company's follow-up offensive. Hopefully they will learn from that, as well.
For a vulnerability as obvious as this, it's a fair bet that bad guys will notice immediately. "Responsible disclosure" is great when you've discovered something tricky, but it's irresponsible when anyone else can notice as easily as you can.
Remember that the term "responsible" is about responsibility to the users, not to the developers. If publicizing a vulnerability would leak it to bad guys who don't have it, the responsible thing to do is not to leak it. If the bad guys already have it, the responsible thing to do is to tell the public. (After all, disclosure is about whether to tell the public, not whether to tell the developers.)
With things like that, especially when revealing it could lead to people using the vulnerability maliciously I don't think it is ethical to release details of it, unless they don't make any indication they are going to fix it.
It is bothersome when they don't even thank you for bringing it to their attention however.
There is no such thing as irresponsible disclosure, therefore there can be no such thing as responsible disclosure.
If a backend is coded this poorly, it betrays irreparable and highly dangerous levels of idiocy, laziness, and lack of foresight in the ones who coded it. Everyone deserves to be informed of this blunder so they know to avoid this group like the plague.
Public ridicule and preemptive destruction of the brand is the only conscionable reaction.
They probably should have shut it down or disabled registrations once it got out until it was tested.
Sorry, but if you put a public site on the Internet, somewhere it can be discovered, and you are prompting people to put in sensitive credentials on that site, then you have launched for practical purposes. You should be implementing security measures accordingly.
If you're not ready for that and just want to show friends, it's not exactly rocket science to add basic HTTP Auth to the site, lock it to specific IP addresses, or any number of other trivial measures that would have prevented this problem.
Before ever putting a service up on the public Internet (service defined here as "accepts arbitrary requests" and "delivers arbitrary responses"), I would hope every human being that knows his way around a text editor treats user data like the Dead Sea Scrolls. If you store a row in a database, you then think of every way that an unauthorized party can gain access to that row and close each in multiple ways. I can recite dozens of cases where user data hasn't been treated with the respect it deserves (i.e., every single Bitcoin disclosure due to newer developers running sites that are handling money).
If people took user data more seriously than they do in general, we'd have a lot less leaks. Imagine if this had gone undiscovered and the service took off? Imagine how many undiscovered vulnerabilities there are in there, with this track record to start?
I can't sympathize with this at all. I just can't.
It should not have been on the public internet without access control for editing/viewing personal information like this - as soon as a site is visible on the internet there are bots trying all conceivable urls on it and scraping for information. If you look in your logs for any server you'll find all sorts of php,aspx etc urls as bots try to find vulnerabilities, no matter what you're running. I'm sure there'll be some Rails scrapers out there too though perhaps they're not too common yet.
There are probably a lot of other holes if they left the user security so wide open.
It shouldn't be something that slips through testing. If you aren't doing that from the start, something is seriously wrong with how you're building out your application.
This incentivizes people to fix things quickly and preserves the reputational value of breaking into things without researcher-vendor relations getting adversarial when you announce something like "I harvested a couple dozen of your customers' API keys" or "Here's an exploitation roadmap you can follow in your browser" in a public forum.