Live data from Hacker News

Never Give Your Information To 10 Minute Old Startups

blog.ryankearney.com

111–120 of 185 posts

Re: Never Give Your Information To 10 Minute Old Startups

#111
post #9

Earlier quoted context omitted.

The last time I used Rails (2009), the way RESTful URLs are set up encouraged this pattern. It's simple enough to restrict access to the user in question, but it is (or was) easy to overlook.

i agree - i cant think of a reason why the user id would ever be in the account url

It's relatively common practice to have an url like this: /yourusername or /users/yourname or /users/32, which shows a public profile, and therefore to have a guessable url for it, and to have a link to edit your account on that page if you are that user.

That in itself is not a security problem, but having no access control obviously is.

Re: Never Give Your Information To 10 Minute Old Startups

#112
post #12

Earlier quoted context omitted.

> Is it considered apropos to state how surprised you are that developers who come across as relatively senior are capable of making an incredibly fundamental security mistake such as this? Only if you're concerned that you can't tell who is "relatively senior." In this case, your judgement was unfortunately wrong.

'Relatively senior' here means 'ostensibly trusted with important tasks in the past'. Both of the creators of this application (I won't say 'founders of this startup' because that's silly) are ex-WePay.

Working in a cool company doesn't automatically mean the developer is competent. Neither is working for a large corp for that matter. I've seen far too many examples of this, unfortunately.

Re: Never Give Your Information To 10 Minute Old Startups

#114

Earlier quoted context omitted.

> It was also a demonstration that the people running the business have absolutely no idea what they are doing when it comes to security, privacy, or testing and release processes. I'm pretty sure a lot of successful startups were started by people who had "absolutely no idea what they were doing". Give them a break...

Yeah, if we couldn't do business with people who ever released software with security holes, none of us would have jobs. The big fuck-up is when they told anyone with key problems to contact the guy who found the issue. That's why we should consider them unprofessional. The security holes were accidents. The blamestorm was deliberate.

Ah ok, I didn't get that part.

Re: Never Give Your Information To 10 Minute Old Startups

#115
post #43
post #34

Earlier quoted context omitted.

we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…

Classy response. Now here's your chance to take lemons and make lemonade. Clearly your pet project is something that people find really interesting and useful. So it went public before you intended and had some security flaws: oh well, that's in the past now. Write your mea culpa about how much you learned from this experience, hit the front page of HN again, sign up a bunch of users, and go get some venture capital.…

Somebody fund this guys 'how to make lemonade' book right now. Best advice on here.

Re: Never Give Your Information To 10 Minute Old Startups

#116
post #34

Earlier quoted context omitted.

we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…

To be honest this is a much better response than the previous on in the other thread. Also, can you explain what "Glacier is built for durability of 99.999999999%" actually means, if not uptime?

Think of durability like the bank telling you that your money is 99.99999999% secure in their vault, but you can only access it from 9 to 5, Monday to Friday. The bank's "uptime" is really low (40 hours / 168 hours * 100%) but your money's "durability" is quite high.

Re: Never Give Your Information To 10 Minute Old Startups

#117
post #27

Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…

I think it's at an entirely different level when it's a brand new company and a trivial security flaw. That just seems like incompetence, and he's absolutely right to suggest not trusting people like that with your data.

It's incompetence (at security), but not malice, and they were willing to fix the problem quickly.

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.

Re: Never Give Your Information To 10 Minute Old Startups

#118
post #34

Earlier quoted context omitted.

I have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.

we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…

Why did you share Ryan's email address in a previous comment and why have't you deleted it yet ?

Re: Never Give Your Information To 10 Minute Old Startups

#119

Earlier quoted context omitted.

I think it has less to do with ORM and more to do with laziness. Its really one line in the controller, if loggedin user is not the user trying to edit redirect.

It's not just laziness. 99% of all framework tutorials I've seen out there completely ignores even basic authentication/authorization issues, which are universal to all real websites. This lack of attention to details is cultivated.

I guess they are using Rails. If they had only taken a few hours to go through a free tutorial like the one at railstutorial.org , they could have avoided this blunder.

Re: Never Give Your Information To 10 Minute Old Startups

#120
post #34

Earlier quoted context omitted.

I have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.

we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…

[deleted]
Post reply on HN