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