Right! I'm just pointing out that this isn't necessarily malice or negligence on the part of the author. Dead Man's Switch has some ways it could be improved, and remembering to set up a CSRF token seems to be one of them.
> It's not malice but solving sensitive problems without taking security seriously can actually have really big consequences for your users.
This is very true - but often the author does intend to take security seriously and they've simply overlooked something. The best approach in that scenario is just to talk to them and ask them to take a look at a vuln you've found, rather than immediately telling all their potential users to stay away.
I'm not some heartless security snob. This is not the first time I've seen this site, and it's been broken for at least a year (when I pointed this out last time). Because of that people SHOULD stay away.
Even if the authors of such services are highly knowledgable about security, they're going to rely on reports from hobbyist security researchers to fill in the gaps. There are major companies out there right now with dedicated infosec departments - and even they have bug bounty programs, because they know they can't catch everything.
I don't imagine this service gets an enormous amount of traffic. You might be among the handful of visitors to the site who are capable of noticing the CSRF issue, and maybe even the only one to go in and look at the source. He's had an email address up on his site for a while (hi@stochastictechnologies.com). Did you report the vuln to the author when you first found it?
That's all perfectly reasonable, and I'm not without sympathy for StavrosK on this.
I'm also not sanguine about the idea of using a service which is meant to handle information of such gravity as this, and which has also had an extremely well understood, trivially fixed, and enormously compromising information disclosure vulnerability go unfixed for a year or more. The reason why that situation has obtained is not interesting to me; that that situation has obtained is enormously so.
This one I agree with. I wouldn't use the service personally until the issue is fixed. But it is so counterproductive to find a security problem the average user wouldn't notice, and then not tell the author about it.
I wouldn't use the service even afterward. The dev didn't think about CSRF for a year. What else didn't he think about?
Don't get me wrong - I think very highly of what 'StavrosK is trying to do here, and I agree that it's counterproductive not to report an issue once found in a case like this. (There's a certain degree of nuance made necessary by the fact that kill-the-messenger reflexes make vulnerability reporting so fraught in general. But that doesn't seem likely to obtain in this case, so I'd report, probably not even anonymously.) But at this point that trust just isn't coming back.
I'm not going to do any more responding. The author of the service is an active HN user and has been for 5 years. I have no idea if I reported the issue by email or not...
Anyone who "cares" about security should know about CSRF. It is one of the 3 attacks that all web devs encounter. It's trivial to find.
The app is written in Django, probably all the way from 0.96. I rewrote it at some point, but I must have forgotten to add the CSRF middleware on an upgrade.
