Never Give Your Information To 10 Minute Old Startups • Hacker News Board

Re: Never Give Your Information To 10 Minute Old Startups

#121

Post by grey-area » Sat, Oct 06, 2012, 8:55 AM UTC

seldo wrote: post #90

Those who know me will laugh to see me continuing to beat this dead horse, but this is a really great example of why ORM+scaffolding is an anti-pattern, by which I mean it seems like a good idea at first, but the costs outweigh the benefits. It's absolutely true that you can use ORM and scaffolding patterns in a totally secure way. But the problem is that the defaults are insecure -- every table can be accessed, ever…

One of the simplest and most fundamental rules of effective security is to close everything down by default and only open things up as required, after careful consideration. Scaffolding breaks that rule.

This is really an argument for building authentication and authorization into every app, rather than against scaffolding/ORMs.

As rails doesn't have auth (of both kinds) built in, it doesn't really matter if they offer scaffolding or not - any editing url you make is going to be completely without protection unless you add it. The only thing you'd be adding by not having guessable urls without authentication/authorization is security through obscurity.

So IMHO the lack of auth is really the issue here (and the thing that breaks the rule in your final sentence), rather than the guessable urls.

Re: Never Give Your Information To 10 Minute Old Startups

#122

Post by nikcub » Sat, Oct 06, 2012, 8:58 AM UTC

patio11 wrote: 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…

My own policy is that each situation is unique and in some cases you have to disclose details upfront.

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.

[1] http://news.ycombinator.com/item?id=4619424

Re: Never Give Your Information To 10 Minute Old Startups

#123

Post by matthewowen » Sat, Oct 06, 2012, 9:43 AM UTC

unreal37 wrote: post #50

clockstrikesten wrote: post #45

Earlier quoted context omitted.

You speak of "responsible disclosure", but what about "responsible launch"? 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.

It sounds like it wasn't launched yet. The founders say they built it for themselves and their friends to start. Someone discovered the URL and posted it to Hacker News. They probably should have shut it down or disabled registrations once it got out until it was tested.

I don't get this. Ensuring that users can't edit/access the profiles of other users is trivial in most frameworks.

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.

Re: Never Give Your Information To 10 Minute Old Startups

#124

Post by oelmekki » Sat, Oct 06, 2012, 9:55 AM UTC

patio11 wrote: 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…

This is not a classic security problem causing a "woops" on border line case. This is a failure to implement 101 basic feature.

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)

Re: Never Give Your Information To 10 Minute Old Startups

#125

Post by oelmekki » Sat, Oct 06, 2012, 10:15 AM UTC

enoch_r wrote: post #95

JoeCortopassi wrote: post #40

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 hi…

> it's somewhat understandable in the context of a site that unintentionally goes public before it's ready

Sorry, but no. There is absolutely no good reason while creating an user controller - even when writing the very first lines - to not check against current user on sensible actions.

Actually, I may argue that's the very first thing you do once the controller skeleton is set up.

Re: Never Give Your Information To 10 Minute Old Startups

#126

Post by nathan_long » Sat, Oct 06, 2012, 10:23 AM UTC

seldo wrote: post #90

Those who know me will laugh to see me continuing to beat this dead horse, but this is a really great example of why ORM+scaffolding is an anti-pattern, by which I mean it seems like a good idea at first, but the costs outweigh the benefits. It's absolutely true that you can use ORM and scaffolding patterns in a totally secure way. But the problem is that the defaults are insecure -- every table can be accessed, ever…

>> One of the simplest and most fundamental rules of effective security is to close everything down by default and only open things up as required, after careful consideration.

Which is why my Rails authorization library takes a whitelisting approach.

https://github.com/nathanl/authority#default_methods

Re: Never Give Your Information To 10 Minute Old Startups

#127

Post by oelmekki » Sat, Oct 06, 2012, 10:25 AM UTC

seldo wrote: post #90

Those who know me will laugh to see me continuing to beat this dead horse, but this is a really great example of why ORM+scaffolding is an anti-pattern, by which I mean it seems like a good idea at first, but the costs outweigh the benefits. It's absolutely true that you can use ORM and scaffolding patterns in a totally secure way. But the problem is that the defaults are insecure -- every table can be accessed, ever…

disclaimer : I don't use scaffolding either

Well, scaffolds are not suppose to totally avoid coding. They try to provide what you may write again and again, but you're supposed to take that as a basis, not a final product.

Re: Never Give Your Information To 10 Minute Old Startups

#128

Post by nathan_long » Sat, Oct 06, 2012, 10:28 AM UTC

ricksta wrote: post #14

I would recommend using CanCan for security if they haven't done so already so you can't just type in other users user_id in the url to view or edit. https://github.com/ryanb/cancan Cancan is great way to make sure that you can only read or edit your own records in the database with Rails.

This kind of thing can be handled with doing something like `current_user.accounts.find(params[:id)` instead of `accounts.find(params[:id])`.

If it's not your resource, it's like it doesn't exist for you.

Re: Never Give Your Information To 10 Minute Old Startups

#129

Post by thisone » Sat, Oct 06, 2012, 10:34 AM UTC

sergiotapia wrote: post #59

Holy shit! I consider myself a mediocre programmer at best and even I wouldn't make such a dumb mistake. This is literally something only a amateur would do. I'm just awe struck that this would even happen. How?

it's something someone would do who's never worked with authentication and authorization before and doesn't have the fallback of a professional tester (aka breaker).

As people have mentioned, rails doesn't have it built in. I've used gems to provide it since I don't trust myself to write good enough security algorithms (and really, why reinvent the wheel if I don't have to).

In .net we can use the asp.net membership. But you've always got to have that authorization part, which I think can get forgotten about unless you've got a system under you belt or something/someone to crib from.

Sometimes you just don't think, and sometimes it becomes very public.

Re: Never Give Your Information To 10 Minute Old Startups

#130

Post by mryan » Sat, Oct 06, 2012, 10:38 AM UTC

whalesalad wrote: post #93

larrys wrote: post #62

Earlier quoted context omitted.

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

This is exactly the same thing - an obvious security oversight that resulted in private information being disclosed, simply by modifying the URL.

The fact that the results are so different is irrelevant - the attack vector was essentially the same.

Also, even with the complete lack of security on this site, it should still not be possible to take any action on the victim's AWS account. IAM has read-only roles for this exact reason - hopefully no-one was negligent enough to post their master AWS key/secret in to this or any other third-party site.