Why the hell do companies think it's trivial to just give away data about huge swaths of its user base? Is it some kind of ego thing, like, they aren't willing to admit it's a security issue, so just pretend like this is a feature and not a bug?
Flickr: Invitations disclosure (resend feature)
31–40 of 93 posts
Re: Flickr: Invitations disclosure (resend feature)
#32Isn't this basically how weev got sent to federal prison?
Re: Flickr: Invitations disclosure (resend feature)
#33A simple fix seems to be to use longer random id for the invitation. As d4d1a179c0f3 mentions, this kind of information could be useful for setting up more targeted phishing attacks. "Hi John, remember the Flickr invite for holiday photos I sent you two weeks ago? I moved my albums to new site, please go to blackhat.org/malwaredl.."
Yeah it would be a fairly simple fix in code: they could hash some of the user data (e.g. email + name) and then append the id to create a token that won't ever collide and is always unique. e.g. - " rel="nofollow">http://www.flickr.com/invite/?resend= -
Sure, of course, but I would caution against playing armchair developer on someone else's product.
I'm sure product decisions I've made seem odd and inscrutable to someone else, but that's because they don't know about the backend interface to a legacy system, etc.
Re: Flickr: Invitations disclosure (resend feature)
#34To fix,this, they should
- make the link protected by login
- accept only post requests
- generate more complicated, hard to guess tokens
Re: Flickr: Invitations disclosure (resend feature)
#35Earlier quoted context omitted.
You don't need to hack someone's account to send mail as them, you just need a server that will get into the popular services. That's the reason social graphs are sensitive, match up people who trust each other and send them messages as each other. Interesting point about password resets though, if you can read (have hacked) the email you're into pretty much any account. BTW in case you're unaware any Android/iOS dev…
> You don't need to hack someone's account to send mail as them, you just need a server that will get into the popular services. They emailed me on an address only used by them in their email, and not in any other service. That only way I could get spam on that address is if their email was hacked. (Either remote, or locally via their desktop.)
What about spoofing?
http://en.wikipedia.org/wiki/Email_spoofing
Re: Flickr: Invitations disclosure (resend feature)
#36I love how publicly posting bugs shifts the balance of power. "schofield" probably though it was just a conversation between Yahoo and the submitter. Now it's a conversation between Yahoo and Hacker News. Welp, the verdict is schofield is being dense. Of course user relationship pairs are potentially sensitive. Therefore enabling attackers to discover them by enumerating your tiny key space is an issue. Either schofi…
Companies need to send out an email to all employees every morning reminding them of the most basic law of corporate communications: "When you speak to a customer, reporter, friend, or any other person not employed by $Company about $Company-related matters, you are acting as a public representative of $Company. Regardless of whom you speak to or in what context, you must assume your words will be repeated to the ent…
Correct
I once worked in a company that had a manual for communications/dealing with the media, etc. And this was given to engineers.
(it was a company that did a product that was bought by governments and had an impact on people, so the chance of being interviewed by the press was higher than average)
Re: Flickr: Invitations disclosure (resend feature)
#37The response to this bug is atrocious and shameful. The developer that responded to this did the same as putting on a blindfold and declaring that because they could no longer see the bug, it must not exist. Right from the get-go, schofield showed incompetence when they declared they couldn't reproduce the bug, even though it was explained to them plainly and thoroughly! How do these inept developers get hired?
I don't think schofield's response was great, but he certainly didn't pretend the submitter was making something up, he just didn't think the information exposed is sensitive. Realistically this isn't a bug in the software, it's an issue with the design of the invitation feature from a legal/UX standpoint. Either the user sending the information should be aware the information is not private and/or the invitations should expire at some point.
Re: Flickr: Invitations disclosure (resend feature)
#38To fix,this, they should - make the link protected by login - accept only post requests - generate more complicated, hard to guess tokens
Regarding your second suggestion, how would allowing only POST requests stop this from being exploited?
POST requests aren't any more secure than GETs[0] in the context of this exploit, so surely it would make no difference if the attacker was forced to send one type instead of another?
It would also mean that the intended recipients of the Flickr invites would be unable to accept them because you can't POST via links in emails.
[0] https://stackoverflow.com/questions/198462/is-either-get-or-...
Re: Flickr: Invitations disclosure (resend feature)
#39I love how publicly posting bugs shifts the balance of power. "schofield" probably though it was just a conversation between Yahoo and the submitter. Now it's a conversation between Yahoo and Hacker News. Welp, the verdict is schofield is being dense. Of course user relationship pairs are potentially sensitive. Therefore enabling attackers to discover them by enumerating your tiny key space is an issue. Either schofi…
Companies need to send out an email to all employees every morning reminding them of the most basic law of corporate communications: "When you speak to a customer, reporter, friend, or any other person not employed by $Company about $Company-related matters, you are acting as a public representative of $Company. Regardless of whom you speak to or in what context, you must assume your words will be repeated to the ent…
Also, maybe my time zones are wrong, but it seems like the engineer changed the bug status to "disclosed" late in the day Friday?
A corollary: Don't do sh*t late Friday that will fester over the weekend.
It makes me mental when people want to "close their week" by deploying a change to a public-facing system. Yes it feels great to check it off your list and start your weekend. But unless you're prepared to deal with it over the weekend -- and got buy-in from the rest of your team they're prepared to deal with it -- please don't.
Re: Flickr: Invitations disclosure (resend feature)
#40The collision rate seems pretty high and to someone with a bit of resources (say 500 ips) to go through the ids would take 3~ days at 1 request per second. The party would have a list of of flickr users / email combinations. The best way to fix this if they want to have the urls work for some backward compatible reason is probably severe rate limiting after x requests if they do not want to expire these requests -- r…
This is not a collision rate. Collision is when two plain text gives the same hash.