I have wrote the whole case here: http://fogmarks.com/2016/10/26/the-beauty-and-the-thoughtful/
But here is a copy-paste for your convenience:
Today’s case-study is based on some recent events and misunderstandings I had with Facebook, and its main goal is to set researchers expectations from bug bounty programs. Both sides will be presented, of course, and you will be able to comment your opinion in the comments section.
So, back in July I have found that it is possible to link between Scrapebooks that users have opened for their pets or family members to the users themselves (who relate to the pet or family member), even if the privacy setting of the user to the pet or family member was set to ‘Only me’.
This was possible to be done by any user, even if the user was not friends with the victim. All he had to do was to access this Facebooks’s mobile URL: m.facebook.com/<SCRAPEBOOK_ID>/
After accessing this URL, the attacker was redirected to another URL: m.facebook.com/<CREATOR_FACEBOOK_USER_ID>/scrapbooks/ft.<SCRAPEBOOK_ID>/?_rdr
and the name and the type of the Scrapebook was displayed, even if the privacy setting of it was set to ‘Only me’ by the creating user (the victim).
12 days after the initial report Facebook said that the issue was ‘not reproduceable’, and after my reply I was asked to provide even more information, so I have created a full PoC video. Watch it to get the full picture and only then continue to read.
So, as you can see accessing the supplied URL indeed redirected the attacker to the Scrapebook account that was made by the victim, and revealed the Scrapebook name – which is not private, and the Scrapebook maker ID (the FBID of the victim user).
5 days after I have sent the PoC video Facebook finally acknowledged it and sent it forward for a fix.
2 months after the acknowledgement I have received a mail from Facebook, asking me to confirm the patch. They simply denied from unauthorized users to access the vulnerable URL and then to be redirected to the Scrapebook.
2 days after I confirmed the patch, I got a long mail reply stating:
Thanks for confirming the fix. I’ve discussed this report with the team and unfortunately we’ve determined that this report does not qualify under our program.
Ultimately the risk here was that someone who could guess the FBID of a scrapbook could see the owner of that scrapbook. The “name” here isn’t a private piece of information: it will show up whenever the child or pet is tagged, for example, and so any changes related to that aren’t particularly relevant here. The risk of someone searching such a large space of potential IDs in the hope of finding a particular type of object (rare) in a particular configuration (even rarer) makes it highly implausible that any information would be inadvertently discovered here. Even if you were to look through the space your search would be untargeted and could not recover information about a particular person.
In general we attempt to determine whether or not a report qualifies under our program shortly after the initial report is submitted. In this case we failed to do so, and you have my apologies for that. Please let me know if you have any additional questions here.
Or in short: Thanks for confirming the fix, we now see after we fixed it that the impact of the vulnerability was able to be achieved after some hard work – iterating over Scrapebook IDs, so the report is not qualified and you won’t be awarded for it.
And now I am asking: How rude can it be to hold a vulnerability for 3 months, fix it, and then, only then, after the fix is deployed in the production and there is no way to demonstrate another impact aspect, say to the researcher: “Thanks, but no thanks”.
This case-study is here to demonstrate researchers the various opinions that exist for every report. In your opinion the vulnerability is severe, a must-fix that should not even be questioned, but in the eyes of the company or the person who validates the vulnerability – it is a feature, not a bug.
I would like to hear your opinion regarding this in the comments section below, on Twitter or by email.