Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flickr: Invitations disclosure (resend feature)

hackerone.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: Flickr: Invitations disclosure (resend feature)

#61

Post by toomuchtodo »

6cxs2hd6 wrote: post #39
nknighthb wrote: post #25

Earlier 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 run ops at my current ship, and my counterpart is our lead developer.

I'm not sure how it works elsewhere, but together we have a very strict "We DO NOT deploy production changes on Friday". New chef script? Monday. Change to how we're sending writes or reads to different DB clusters? Monday.

I do not know why this isn't the norm in more places.

Re: Flickr: Invitations disclosure (resend feature)

#62

Post by e28eta »

I saw a similar issue with a company that sold tickets to events several years ago. They sent me an email with a link to my e-ticket. The URL had a sequential id, and there was no auth/verification that I was the one who purchased it.

So, I took a look at the person who ordered before me, and was able to view their name/address, and could have printed their tickets to the event!

Re: Flickr: Invitations disclosure (resend feature)

#63

Post by KMag »

sugerman wrote: post #37
kintamanimatt wrote: post #6

The 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 sh…

Expiration helps very little if the valid IDs are still easily enumerable. Access control, not expiration, is what is called for here.

Edit: expiration would limit the scope of data leakage, and should also be looked into, but expiration without access controls still allows patient attackers to collect all of the data being generated and store it for future use.

Re: Flickr: Invitations disclosure (resend feature)

#64

Post by mukyu »

aw3c2 wrote: post #47
jcromartie wrote: post #32

Isn't this basically how weev got sent to federal prison?

No, there is a difference between accessing things and publishing things with malicious intent.

Most people would not call only releasing the data to a journalist "publishing", and much less "with malicious intent".

weev didn't put his dump up on the pirate bay, he sent it to Gawker.

Re: Flickr: Invitations disclosure (resend feature)

#65

Post by mathias »

Joshu42 wrote: post #27

it's really easy to capture contacts this way. As Mathias said, they have to limit the view of the saved form to the one who sent it in the first place... and add an expiration for deleting such data. So what's missing ? an ID for knowing the first sender, a timestamp, a checking process and a garbage collector to delete the expired ones periodically ? Ok, we don't add a column so easily in the big DB table here, but…

Minor correction: it was “d4d1a179c0f3” who reported and suggested that solution, not me (although I agree with their proposal). I’m just the guy who posted this on Twitter (https://twitter.com/mathias/status/452714683628527616) and Hacker News.

Re: Flickr: Invitations disclosure (resend feature)

#66

Post by markbnj »

Can we not call this a "bug?" It's clearly a design weakness and "schofield" said it was working as intended, ergo not a bug, but just a poor choice of mechanism. Pretty humorous that "schofield" thought it was fine the way it is. Guess that has been cleared up by the internet. It's pretty trivial to generate a random, non-guessable, unique code to use as a lookup key for the invitation, and I guess that's what they've done.

Re: Flickr: Invitations disclosure (resend feature)

#67

Post by alceufc »

orblivion wrote: post #52
tszming wrote: post #46

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

Relations are another interesting thing. That would make phishing much more effective. Though I suppose somebody's Yahoo profile page should get them access to that as well.

There was also the invitation text which might contain private messages.

Re: Flickr: Invitations disclosure (resend feature)

#68

Post by secalex »

Hey, HN, CISO of Yahoo here, typing on a phone at a kid's birthday, so excuse the formatting.

We run a very progressive bug bounty program that allows bugs like this to be posted publicly. Every once in a while we might miss something out of the thousands of invalid reports we receive every month, and we made a mistake in the triage of this bug. The bug is fixed and we won't make the same mistake again. We definitely consider info disclosure to be a class of issue that needs to be addressed and to infer otherwise from one mistake is incorrect.

There are a handful of companies experimenting with this kind of open bounty model, and if we want it to survive (I certainly do) then we are going to all have to be willing to iterate to fix the problem, and move on.

Re: Flickr: Invitations disclosure (resend feature)

#69

Post by tomcorrigan »

secalex wrote: post #68

Hey, HN, CISO of Yahoo here, typing on a phone at a kid's birthday, so excuse the formatting. We run a very progressive bug bounty program that allows bugs like this to be posted publicly. Every once in a while we might miss something out of the thousands of invalid reports we receive every month, and we made a mistake in the triage of this bug. The bug is fixed and we won't make the same mistake again. We definitely…

That's great, but you were aware of this issue for a month. If the whole point of having a bug bounty program is that you benefit from the distributed intelligence of the community you should perhaps place a bit more faith in your unpaid and unrewarded labor. Do you really receive thousands of invalid security reports every month or is user Schofield way out of their depth.

Why should another dev ever bother submitting a security issue to Yahoo if they have to deal with such obstinate silliness?

Re: Flickr: Invitations disclosure (resend feature)

#70

Post by michiel3 »

nknighthb wrote: post #43
6cxs2hd6 wrote: post #39

Earlier quoted context omitted.

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

That is correct. The reporter requested public disclosure after the report was closed. The bug automatically gets disclosed publicly 30 days after the report is closed, unless the team requests more time by re-opening the bug. You can read more about the disclosure philosophy here: https://hackerone.com/guidelines
Post reply on HN