Hacker News Reader

Comment by Silhouette | Hacker News Reader

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 prefer to assume naivety rather than malice.)

Unfortunately, the only sensible action when faced with a business like this is to run away and not look back for a very long time, except perhaps to check who the people responsible were so you can avoid anything else they work on in the near future as well.

View on HN

"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 to do was place a single order so they shipped to you. Although I guess it wouldn't have been even easier to social engineer someone to simply give you any tracking number and save that step.)

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.

The results absolutely do matter. If you're running a site, you should be auditing the areas where the security risk is the greatest and taking extra precautions, and those areas are hopefully few. If you're not first taking care of the places where the results are disastrous, then you're doing it wrong.

Obviously if there is a known attack vector, you would fix any similar issues everywhere, but not all code is the same.

The point I was making is that this particular flaw is indeed the same as the UPS flaw when considered at a high level - modifying a URL caused sensitive data to be disclosed.

In practical terms, of course the nature of data that is disclosed is relevant. AWS keys are incredibly valuable, and should be treated as such.

Wait, does rails scaffolding turn off security by default?

Fair point, though of course that was at a time when most of the world hadn't even heard of the World Wide Web yet. Most people running web sites handling sensitive information have learned a lot of lessons since then.

And a lot of today's startup community was watching Sesame Street

That’s a really interesting anecdote, but not fully thinking through the security implications of the Web in 1996 is not the same thing as royally screwing up in 2012.

All I can say to that is thank Christ it's not 1996 anymore.

That hasn't changed. You can pop a tracking number into UPS and get shipment info.

Currently given a tracking number you can only get the following info:

Package weight

Shipping date

Who signed for it (last name)

Where package was left

Town delivered to

When delivered

And some other nominal info.

In the old days you saw exactly who the shipper was and detailed info on the recipient and recipients address. There was probably other info but what I've listed is what I remember. I remember thinking at the time that it would be valuable and contain exactly what a competitive company would need to gather a list of potential customers.

> a business that made a mistake like this

I go one step further. I refuse to give information that provides more access to a business than they need to have or that can even affect any other service I receive from anywhere else.

Here, I'd like to give them a key that works only with glacier vaults that they have created, and nothing else. If this isn't possible, then I'll go without.

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

Reply on news.ycombinator.com