[dsacco]

I'd be willing to bet a five figure sum that this plan would work either not at all, or for less than a week.

The vulnerability itself is interesting, and more prone to monetization utility than the standard fare of bug bounty reports that get posted here, so I'll give you that.

However, Facebook has one of the most sophisticated anti-scraping/crawling systems I have ever seen in production. Automating this with any non-trivial scale would immediately alert several teams, especially in security, risk, QA and analytics.

This is assuming that you could realistically automate the act of inviting and uninviting non-friends without any penalization. In fact, what would probably happen is a rate-limit trigger that would temporarily knock out access from your IP address. There are also account-level rate limits, not just IP-level.

Realistically, I'd use this for targeting a specific person in order to get their private contact information. I suppose that could actually be worth something, like if someone wanted a well known VC's private email address. But it's an odd length to go to nowadays when most professional emails are pretty guessable.

[mysterypie]

> Facebook has one of the most sophisticated anti-scraping/crawling systems

Not only that, Facebook has a such a sophisticated security design that prevents leaking of private information in the first place. Oh, wait... /Irony.

I don't understand why FB can be so sloppy in one aspect of security and yet you claim that they are brilliant in another aspect of security. It's possible. It's possible that some guy never washes his hands, his hands are completely filthy, but his clothes are always impeccably clean. That's possible too. Just unlikely.

[dsacco]

You started with two mistaken premises, which makes your analogy a poor comparison:

1. Facebook doesn't have "sloppy" security. The company and its software are massive and have many, many participants involved in the product and software development loop. You have unrealistic expectations for a company of that size with a consumer-facing product. Facebook continually recruits the best available talent in the security industry and empowers them to do their jobs without shooting themselves in the feet or getting kneecapped by cavalier product design. They also produce some of the best security research and implement best practices wherever they can.

I want you to look through any of Facebook's main or subsidiary applications and tell me how quickly you can identify CSRF, XSS, SQL injection, or a logical ACL failure like the one presented in this report. What you are not seeing is the utter deluge of bug bounty reports Facebook receives as a company and the nearly impeccable track record it has. The company receives over 80,000 reports each year, and fewer than 10% are valid security vulnerabilities. A tiny portion of those could be classified as "high" or "critical" severity.

You are also not seeing the meticulous, continually running machine that is the overall Facebook security organization. Not only are bug bounty participants aggressively recruited at Facebook, they are frequently put in charge of maintaining one of the most successful and recognizable bug bounty programs in the industry. Have a read through Ryan McGeehan's writings and presentations for a bit of insight into how much investment Facebook has put into incident response and security tooling in the past decade.

2. On a more technical level: rate-limiting is vastly simpler than overall security vulnerability resolution. It is comparatively straightforward to implement a rate limiting system with enough sophistication to combat a sizeable botnet attempting to crawl through a web application or automate user actions. Facebook does this using a variety of heuristics and even machine learning, with collaboration between the security (incident response), risk and data analysis teams doing the heavy lifting. While the work itself might not be easy, the deliberables and outcomes for such a system are very clear. In contrast, application security is a hard problem which primarily results from a software implementation that doesn't match the design spec (logical errors) or a design spec which fails to correctly incorporate a risk assessment. It is not straightforward to eliminate every vulnerability, because you can't just write a script that proves immunity from the OWASP Top Ten and be done with it.

[tedunangst]

It shouldn't be surprising. The whole point of Facebook is sharing information. Not much point to a social network if your friends can't see a thing you post. Permeable membrane is permeable.

[motoboi]

>This is assuming that you could realistically automate the act of inviting and uninviting non-friends without any penalization. In fact, what would probably happen is a rate-limit trigger that would temporarily knock out access from your IP address. There are also account-level rate limits, not just IP-level.

I think you are underestimating the capabilities of botnets and what you can buy from them with a handful of dollars.

[dsacco]

No, I fully understand that, which is why I said "probably." However, it would be a sophisticated botnet to challenge Facebook's rate limiter, and moreover, it would still have the problem of producing an excessive amount of noise when Facebook saw an influx of users and IP addresses continually inviting and uninviting other users.

[Jake232]

From personal experience I can actually say scraping Facebook, although not trivial, is also not as difficult as you would likely expect, and their rate-limiting is pretty lenient.

IP's/Accounts are very easily to come by these days.