IVD: Automatic Learning and Enforcement of Authorization Rules in Online Social Networks Paul Marinescu † , Chad Parry † , Marjori Pomarole † , Yuan Tian ‡ , Patrick Tague ‡ , Ioannis Papagiannis † † Facebook. {pau, cparry, mpomarole, yiannis}@fb.com ‡ Carnegie Mellon University. {yuan.tian, patrick.tague}@sv.cmu.edu Abstract—Authorization bugs, when present in online social networks, are usually caused by missing or incorrect autho- rization checks and can allow attackers to bypass the online social network’s protections. Unfortunately, there is no practical way to fully guarantee that an authorization bug will never be introduced—even with good engineering practices—as a web application and its data model become more complex. Unlike other web application vulnerabilities such as XSS and CSRF, there is no practical general solution to prevent missing or incorrect authorization checks. In this paper we propose I NVARIANT DETECTOR (IVD), a defense-in-depth system that automatically learns authorization rules from normal data manipulation patterns and distills them into likely invariants. These invariants, usually learned during the testing or pre-release stages of new features, are then used to block any requests that may attempt to exploit bugs in the social network’s authorization logic. IVD acts as an additional layer of defense, working behind the scenes, complementary to privacy frameworks and testing. We have designed and implemented IVD to handle the unique challenges posed by modern online social networks. IVD is currently running at Facebook, where it infers and evaluates daily more than 200,000 invariants from a sample of roughly 500 million client requests, and checks the resulting invariants every second against millions of writes made to a graph database containing trillions of entities. Thus far IVD has detected several high impact authorization bugs and has successfully blocked attempts to exploit them before code fixes were deployed. I. I NTRODUCTION Modern online social networks (OSNs) handle large amounts of user data. These data are often generated by users, are associated with their accounts and are subject to access control rules governing who can read, create, modify, and delete them. Because OSNs enable many types of user interactions, with different levels of permissions, writing and enforcing these rules quickly becomes nontrivial. Developers need to flawlessly consider all possible interactions and cor- rectly implement the appropriate checks while at the same time iterate quickly to satisfy business needs. OSNs are constantly evolving, with new features being added regularly, often in an arms race to offer their users an improved experience and more ways to express themselves, which often concretizes in new types of interactions. For example, users may use private messaging for a one-to-one or a group conversation, in which case only the participants should be allowed to send and receive messages associated with the conversation and only participants or the conversation moderator, depending on policy, should be allowed to add people to the conversation. Furthermore, messages may be edited in a short time interval after they were sent, but only by the same person who sent them. Users may also interact by posting content to their personal page, usually unrestricted, or to a group, usually only after being explicitly accepted in the group. They may also create connections (e.g. befriend, follow, connect, become a fan, add to circles) with other users, which often gives them additional ways to interact. Authorization becomes even more difficult when multiple types of entities and delegation are involved. For example, an OSN can support personal users, businesses, and a many- to-many business administrator relation between them. Users connected by the business administrator relation are authorized to act on behalf of the business in matters such as changing the business address or answering customer messages. In addition to this, a different relation, business owner, allows users to merge two businesses into a single entity. Proper authorization for the merge requires checking that the logged-in user is the owner of both businesses. Failing to perform correct authorization checks leads to authorization bugs. Attackers can exploit them to impersonate other users, perform actions on their behalf and gain access to data. While all businesses can be negatively affected by such bugs, OSNs are particularly sensitive: they contain large amounts of user data, e.g. their pictures, personal interests, job applications, physical location, and are home to their users’ online personas. In consequence, an OSN’s reputation depends heavily on user trust. However, missing or incorrect authorization checks are a common issue. The Open Web Application Security Project (OWASP) lists authorization bugs as the cause of two of the top ten most common and important classes of web application vulnerabilities [1]. In addition, authorization bugs are easy to exploit if found. Typically, a malicious actor approaches such an attack by trial and error: they first understand the API of a web application by inspecting its normal functionality, they identify the arguments that these APIs receive, and finally send requests with systematically modified arguments and check whether the application performed any action on the object identified by the recently modified argument. The low success rate of each attempt is balanced out by the short time needed to devise the attack, the possibility of automating it, and by its simplicity and accessibility.