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

71–80 of 93 posts

Re: Flickr: Invitations disclosure (resend feature)

#71

Post by donohoe »

tomcorrigan wrote: post #69
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 submitti…

Did you not read the part where they stated they missed this one and didn't remedy it as they should have?

Re: Flickr: Invitations disclosure (resend feature)

#72

Post by 6cxs2hd6 »

michiel3 wrote: post #70
nknighthb wrote: post #43

Earlier quoted context omitted.

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

Thanks for explaining that.

So maybe a feature-request for hackerone would be, don't auto-disclose on Fridays; instead bump to Monday. :)

Re: Flickr: Invitations disclosure (resend feature)

#73

Post by pyronite »

peeters wrote: post #59
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?

Why do you think schofield is a developer? I didn't see any indication in this conversation. Every company I have worked for has a support organization that deals with customer tickets like this. They might escalate the issue to development, or they might not. But either way they're the ones involved in the conversation.

Agreed. kintamanimatt jumped to that conclusion.

Re: Flickr: Invitations disclosure (resend feature)

#74

Post by gaadd33 »

omegote wrote: post #55
vidarh wrote: post #9

Earlier quoted context omitted.

Furthermore, Yahoo can not unilaterally choose to define what is "sensitive". In the EU, many countries implementation of the Data Protection Directive considers e-mail addresses personally identifiable information, which makes it subject to the relevant laws. Given that Yahoo operates in a number of European countries, and have offices and legal entities in many of them, this potentially means they are legally liabl…

Indeed. In Spain, the LOPD (Data Protection Law) states that the email is personal information. Many companies have been fined for leaking emails, specially when sending mass emails with all the addresses in the "To:" field instead of BCC.

Are First/Last names personal information in Spain too? So a customer list would also have the same protections?

Re: Flickr: Invitations disclosure (resend feature)

#75

Post by hnriot »

nknighthb wrote: post #25
abalone wrote: post #5

I 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…

where I work they do and they require online training and signing (electronically) a statement to the effect that you understand. of course that doesn't mean it doesn't happen all the time. Your suggestion is about as useful as a chocolate fireguard I'm afraid.

Re: Flickr: Invitations disclosure (resend feature)

#76

Post by merijn481 »

Yahoo has fully embraced working with security researchers. For a company their size (they're no. 1 in web traffic!) with that many different services, they're doing an amazing job. No company that size has ever moved this fast. Yes, they're catching up but they do it fast!

Re: Flickr: Invitations disclosure (resend feature)

#78

Post by dang »

mathias wrote: post #77

Looks like someone just changed the title of this HN submission. For the record, it originally said: “Full name and email for every Flickr invite ever sent can be viewed by anyone”, which was accurate at the time of posting.

I changed the title in accordance with the HN guidelines.

Re: Flickr: Invitations disclosure (resend feature)

#79

Post by epriest »

tomcorrigan wrote: post #69
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 submitti…

> Do you really receive thousands of invalid security reports every month or is user Schofield way out of their depth.

Although our project is much smaller, we also run a bounty program through HackerOne, and publish aggregate results every month. You can see them under the "Security" headers of the changelog for the last few months to get a quick sense of the overall composition of reports that come through a channel like this, at least for our project:

http://phabricator.org/changelog/

For example, last month we received 49 reports, of which we believe 5 were legitimate security issues which we fixed and awarded. Although the signal on this channel is extremely valuable, it's embedded in a lot of noise, and separating the two is often difficult and time consuming. It wouldn't surprise me if we made mistakes with a few reports even at this relatively small scale, and we have a much easier task than larger projects do.

I'm extremely supportive of HackerOne, but I'm always a little worried we'll make a mistake and end up tried in the court of public opinion when we triaged >99% of the reports correctly and the overall impact of the program is hugely beneficial for researchers, for us, and for our users.

Of course, we should be aiming for 100%, and getting it right almost all the time isn't a free pass for the cases when things go wrong, but seeing just the cases where an issue wasn't handled correctly discards a lot of context.

Re: Flickr: Invitations disclosure (resend feature)

#80

Post by toomuchtodo »

toomuchtodo wrote: post #61
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 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.

s/ship/shop
Post reply on HN