171–180 of 185 posts
Earlier quoted context omitted.
With the title of TFA.
Fortunately, you don't give App.net your credit card information directly. It's handled by Stripe, and they're past being "10 minutes old". (Even though this isn't easily verifiable in the checkout flow to a non-developer.)
Mannnnnnn, this exploit is SO 4 hours ago... ;D
Tell me that blog post didn't read like a security exploit announcement...
Anyways, as discussed, it never should've happened in the first place, but it sounds like from the comment threads that it was likely Framework related, so.... yeah, still prettty bad.
Ryan, your post is NOT an example of responsible disclosure. You could have written your post and posted it AFTER alerting the Ice Box Pro guys and waiting until they had the main issues fixed. Your post would still be a good post. In fact, you seem to weigh the importance of your post getting on HackerNews above the security of the people who tried Ice Box Pro. The creators of Ice Box Pro had good intentions and mes…
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…
Sorry, but I think you're being far too kind. A policy of so-called responsible disclosure is a reasonable approach to take when dealing with an established product/service that contains a minor vulnerability, something potentially dangerous but unlikely to be exploited in the immediate future with serious negative effects. In this case, we appear to have a new project run by people who don't know what they're doing,…
With responsible disclosure, only the original poster and anyone else who happened to figure this out would know. Now everyone does, and any random attacker can just go to the site and harvest AWS credentials from anyone signed up.
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.
Sorry, but I think you're being far too kind. A policy of so-called responsible disclosure is a reasonable approach to take when dealing with an established product/service that contains a minor vulnerability, something potentially dangerous but unlikely to be exploited in the immediate future with serious negative effects. In this case, we appear to have a new project run by people who don't know what they're doing,…
It's not about kindness toward the people running the service, it's about kindness toward the service's users who are potentially compromised. With responsible disclosure, only the original poster and anyone else who happened to figure this out would know. Now everyone does, and any random attacker can just go to the site and harvest AWS credentials from anyone signed up.
In a position where no choice of action/inaction is guaranteed to be harmless, I think limiting the damage is probably the most practical choice, and certainly a reasonable one. It limits the number of potential victims, and it also serves as a warning to those developing future sites that this sort of screw-up is not acceptable.
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…
EclipseLink ORM http://wiki.eclipse.org/EclipseLink/Examples/JPA/Multitenant
PostgreSQL Veil add-on: http://veil.projects.postgresql.org/curdocs/index.html
Multi-tenant Data and MySQL (trigger + view method): http://blog.empowercampaigns.com/post/1044240481/multi-tenan...
MSDN Multi-Tenant Data Architecture: http://msdn.microsoft.com/en-us/library/aa479086.aspx
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).