Live data from Hacker News

Never Give Your Information To 10 Minute Old Startups

blog.ryankearney.com

91–100 of 185 posts

Re: Never Give Your Information To 10 Minute Old Startups

#91
post #58

Earlier quoted context omitted.

I'm generally with you, but I do hope that this tarring and feathering will drive home one point: 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.

"The user ID in the URL like this is a giant "try editing me and see what happens" sign" What's really surprising is that apparently the dev on this never viewed any porn on the internet.

Could you elaborate? I fail to see the connection.

Re: Never Give Your Information To 10 Minute Old Startups

#92
I'd love to see some concrete suggestions on the right way to do security for a site like this. This would take far more than protecting a few web pages from unauthorized access. What else should they do? How should they store sensitive data like AWS keys? Should they include a feature to force the creation of a new temporary key to prevent users from naively storing their master key? Is there a better mechanism than storing the key?

Re: Never Give Your Information To 10 Minute Old Startups

#93
post #62

10 minutes? Never give your information to a business that made a mistake like this, ever . That wasn't merely a "security vulnerability". 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. (Actually, there is an alternative explanation, which is even worse: they knew and didn't care. I pref…

"Never give your information to a business that made a mistake like this, ever." Fwiw back in 1996 or 97 the UPS website did the same thing. By altering the tracking number you could see somewhat complete information on someone else's shipment. Since the tracking numbers ran in sequence from the shippers log books giving one tracking number from a competitor you could see all their customers. (To get that all you had…

Totally not the same thing. Not even close. Knowing a tracking number is nothing compared to having access to someone's AWS account. That's like saying knowing where someone's car is parked is the same as having their keys and a full tank of gas.

I agree with silhouette. These guys scaffolded a rails project and and then slapped bootstrap on it. You can't trust an MVP this extreme.

Re: Never Give Your Information To 10 Minute Old Startups

#94

Security stuff aside, I'm curious why a system would be designed this way. Surely (in most systems) all users have the same page for managing their account (eg: /account) or is this system designed so that the management portion (eg: what a support person would use) is the same as what the users use? I don't think I've encountered a site that had accounts edited this way before.

don't confuse the URL structure with the application design. just because the url is /user/87/edit doesn't mean that there is a file called edit inside a folder called 87. almost any modern web development framework lets you create whatever URLs you want. i'm sure, internally, that every user's edit panel is powered by the same code.

It's a Rails application and it does reflect the structure. It's the edit action on a controller, likely the UsersController. It looks like they tried to implement a user management system using has_secure_password and didn't know enough to do it properly.

They therefore created a default resource structure (probably using the rails scaffold generator command) which includes the id in the URL on all member routes, including the route for the edit action.

Re: Never Give Your Information To 10 Minute Old Startups

#95

Everyone here that is thinking of giving this company the benefit of the doubt needs to go read their (smeagle) responses to RKearney from the original thread. Here are some samples of the careless attitude behind this: ---- "if anyone's concerned about your AWS key, just destroy your IAM user and create a new one. that's what it was designed for." ---- In response to advice saying they should notify users by email:…

I was slightly sympathetic to them right up until smeagle posted RKearney's email. While not noticing an incredibly obvious security hole is serious, it's somewhat understandable in the context of a site that unintentionally goes public before it's ready. What's far, far worse is the mindset in which someone who points out a security hole is the problem, and should be personally attacked.

They should have thanked him, notified their users, done a thorough review of their own security, and warned new signups to only use IAM keys. Instead they got defensive, made excuses, and attacked the messenger.

Re: Never Give Your Information To 10 Minute Old Startups

#96

I'd love to see some concrete suggestions on the right way to do security for a site like this. This would take far more than protecting a few web pages from unauthorized access. What else should they do? How should they store sensitive data like AWS keys? Should they include a feature to force the creation of a new temporary key to prevent users from naively storing their master key? Is there a better mechanism than…

One appropriate way to do this is to not build this type of application as a web service, but instead as a standalone application. (Disclaimer: I haven't really tried this product, for obvious reasons.)

Re: Never Give Your Information To 10 Minute Old Startups

#97
At first, I thought I was supposed to notice the complete lack of "HTTPS" in the URL bar.

The data leakage obviously overshadows it, but I can't think of a site that wouldn't be a better "fit" for SSL encryption than an app like this, aside from banking/government sites.

SSL might have been a "nice-to-have" back in the day when there were real arguments to be made against it (mostly performance-related), but even those don't really apply to a "pet project" made by "two nerds" (smeagol's words, not mine.) And for an app like this, I think it's critical.

Just my two cents.

Re: Never Give Your Information To 10 Minute Old Startups

#98
post #91
post #58

Earlier quoted context omitted.

"The user ID in the URL like this is a giant "try editing me and see what happens" sign" What's really surprising is that apparently the dev on this never viewed any porn on the internet.

Could you elaborate? I fail to see the connection.

Not sure what the parent is referring to, but back in the day you'd have porn preview galleries with no index, but with an easily enumerable id in the URL. Ah, youth...

Re: Never Give Your Information To 10 Minute Old Startups

#99

Everyone here that is thinking of giving this company the benefit of the doubt needs to go read their (smeagle) responses to RKearney from the original thread. Here are some samples of the careless attitude behind this: ---- "if anyone's concerned about your AWS key, just destroy your IAM user and create a new one. that's what it was designed for." ---- In response to advice saying they should notify users by email:…

I'm a big fan of responsible disclosure, and I think that the HN crowd has far too much of a one-track mind about "always disclose security problems everywhere!", especially with something that may not have been ready for release.

But that "contact Ryan if anything goes wrong" is grade A asshole.

Re: Never Give Your Information To 10 Minute Old Startups

#100

10 minutes? Never give your information to a business that made a mistake like this, ever . That wasn't merely a "security vulnerability". 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. (Actually, there is an alternative explanation, which is even worse: they knew and didn't care. I pref…

> 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...

Post reply on HN