To fix,this, they should - make the link protected by login - accept only post requests - generate more complicated, hard to guess tokens
I think making longer and more complicated token is enough.
Flickr: Invitations disclosure (resend feature)
41–50 of 93 posts
Re: Flickr: Invitations disclosure (resend feature)
#42Earlier 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. 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
I think 'ars is saying that these are "personalized" email addresses: there is a separate one for each person from whom 'ars wants to receive email. Assuming these addresses aren't easily guessable/enumerable, and aren't on any lists stolen from or sold by service providers, the spammer must have have gotten them somewhere else.
Re: Flickr: Invitations disclosure (resend feature)
#43Earlier quoted context omitted.
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…
I haven't used hackerone myself, so this is just based on limited observation, but it looks to me like it was automatically disclosed one month after the reporter made the request. Otherwise, I believe it would have said something like "schofield agreed to make this public".
Re: Flickr: Invitations disclosure (resend feature)
#44To 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 link…
Maybe this is a repetition of that old "POST-only prevents CSRF" myth?
Re: Flickr: Invitations disclosure (resend feature)
#45To 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 link…
Allowing only POST requests can help for one simple reason - it's harder for people to share the link without knowing what they're giving away.
Of course, using POST is not the only solution here (requiring the invitation to be by the signed-in user is way better), and it can represent a UX problem (refreshing causes the dreaded "form resubmit" warning).
But it's not a no-op. It does have effect in security in practice, even if it doesn't in theory.
Re: Flickr: Invitations disclosure (resend feature)
#46Actually the Yahoo! employee (schofield?) in the above link is right and you cannot blame him for this - it is because Yahoo! really think first name + last name + email are not private information AFAIK, not particularly to Flickr, there are multiple ways to retrieve these information...
Re: Flickr: Invitations disclosure (resend feature)
#47Isn't this basically how weev got sent to federal prison?
No, there is a difference between accessing things and publishing things with malicious intent.
Re: Flickr: Invitations disclosure (resend feature)
#48The 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.
No, collision is not exclusively for hashes. The term can be used for any area where there's a high ability to encounter a value already in use. In this case, by guessing or incrementing.
Re: Flickr: Invitations disclosure (resend feature)
#49Actually the Yahoo! employee (schofield?) in the above link is right and you cannot blame him for this - it is because Yahoo! really think first name + last name + email are not private information AFAIK, not particularly to Flickr, there are multiple ways to retrieve these information...
Can you tell us about them?
Re: Flickr: Invitations disclosure (resend feature)
#50This bug was fixed just seconds ago. The power of HN :)
You can still load the invite/resend page, but you won't get any user info from it.