141–150 of 185 posts
Earlier quoted context omitted.
Why did you share Ryan's email address in a previous comment and why have't you deleted it yet ?
On Hacker News, you cannot delete or edit a comment except during the first 2 hours of the comment's existence.
The truth is that I don't remember working on a single codebase that didn't have some eventually discovered vulnerability in auth(entication|orization). When I eventually do comb through controllers and find easily exploited access-control violations, I've often been met with responses similar to the behaviour of the developers at Icebox.
Rails does and will continue to protect you from a lot of mistakes, but nothing is going to help long term unless you know what words like authentication, access control and session management mean.
If you're a professional web developer and you care about your users then please buy and have a read through The Web Application Hackers Handbook[1]. Every page is dripping with easily exploitable attacks you didn't think of. That last app you built is almost definitely vulnerable to a handful of them.
[1] http://www.amazon.com/gp/product/1118026470?ie=UTF8&tag=...
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.…
You can even create your own custom filters.
http://www.youtube.com/watch?v=BsxUsyMSGeA
Just letting you know. :)
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…
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.
Earlier quoted context omitted.
If it's accessible on the public internet and asks for something as secure as API keys, that is when you should worry about security, not when it's "meant to be picked up by HN".
Fair, but in any case, the ultimate responsibility still lies with the user's judgment. Maybe if there was a service promised but not rendered, could you place full blame on the developer(s).
Earlier quoted context omitted.
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…
The mistake betrays so much incompetence that there is really no way for me to trust anything they ever do again. The other mistakes they make might not be quite so easy to find.
Just yesterday we had someone publish a "securely delete your email" application. 'tptacek found problems in it immediately[1], but he didn't call the guy incompetent or an idiot or "never trust anything he does again." There was no attempt to shame.
I see the more experienced people around here have a lot more sympathy for these guys. If you've done a lot, you've also had some public mistakes. You grow empathy.
I do find the company's follow-up offensive. Hopefully they will learn from that, as well.
Earlier quoted context omitted.
Honestly, this isn't even a matter of engineering. I don't know the rails solution, but a quick-and-dirty solution in other frameworks is to use a decorator on your controller/views that does something like: if request.session.userId == action.userId: pass else: return SecurityExceptionResult The example above is like 10 mins to code and put under test once you fill it in with the necessary stuff- You're probably goi…
What do you call the role of the individual whose job it is to implement account management? Do you not call that person an engineer? If not - whose responsibility would you say it is to ensure shit like this doesn't happen?
My point was the amount of time required to prevent security holes like the ones outlined in the link are minimal - preventing them isn't going to stand in the way of an engineer implementing other features.
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.
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…
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.
http://pragprog.com/book/rails4/agile-web-development-with-r...