Business directory and crowd-sourced review service, Yelp, has open-sourced their in-house security testing framework, fuzz-lightyear, that identifies Insecure Direct Object Reference (IDOR) vulnerabilities.
Yelp identified IDOR vulnerabilities as not only high-risk, but also particularly difficult to prevent and detect. Fuzz-lightyear uses stateful Swagger fuzzing to identify IDOR vulnerabilities, and has been designed to ensure this can be integrated with continuous delivery pipelines.
Swagger is an open-source software development framework for RESTful web services that enables APIs to self-describe their own structure. Swagger can generate a YAML or JSON file that contains a detailed description of the entire API. The ability to self-describe an API provides several opportunities: documentation can be automatically built, multi-lingual client libraries can be generated, and the generated specification can be leveraged for automated testing.
Fuzzing is a testing technique that can be used to discover security vulnerabilities. This approach provides large amounts of random data as input, called "fuzz", to the test target. The target application is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.
Application security engineering manager at Yelp, Aaron Loo, explains in his blog post announcing the availability of fuzz-lightyear that a common industry recommendation to prevent IDOR vulnerabilities is to use a mapping, such as a random string, to make it harder to enumerate values as an attacker. However, maintaining a mapping will likely lead to either cache management issues that impact SEO or challenges around inconsistent internal reference methods. Loo explores the problem with this attack vector further in his article:
Another common industry recommendation is to merely perform access control checks before manipulating resources. While this is easier to do, it's more suitable for spot-fixing, as it's a painfully manual process to enforce via code audits. Furthermore, it requires all developers to know when and where to implement these access control checks.
Yelp's view on detection strategies is that they aren't any better than the prevention strategies: penetration or vulnerability testing is hard to scale, and can be expensive. Static Analysis Security Testing (SAST) tools also create 'noise'. The team also considered traditional API fuzzing:
The issue with traditional fuzzing is that it seeks to break an application with the assumption that failures allude to vulnerabilities. However, this is not necessarily true. As a security team, we care less about errors that attackers may or may not receive. Rather, we want to identify when a malicious action succeeds, which will be completely ignored by traditional fuzzing.
Loo refered to a research paper published by Microsoft in February 2019 that described how stateful Swagger fuzzing was able to detect common vulnerabilities, including IDOR, in REST APIs. This was achieved by having a user session execute a sequence of requests up to a certain point, and then making an attacker's session execute the same sequence of requests in order to ensure that the user and the attacker are able to reach the same state. For the final request in the sequence, making the attacker's session execute the user's request and producing a successful result detects a potential vulnerability.
This research inspired the team to consider a Swagger fuzzing solution for their IDOR vulnerability problem. This allowed them to consider testing scenarios that were not focused on whether an application breaks for a specific user, but instead focused on successful requests in situations where they should have failed. Loo explains how:
Swagger, as a standardised API specification, is fantastic for programmatically defining the rules of engagement for the fuzzing engine. Furthermore, by making it stateful, we can simulate user behaviour through proper API requests/responses which keep state between each response. This state can then be used to fuzz future request parameters so that a single request sequence is able to accurately simulate a user's session, enabling chaos engineering testing.
The Yelp team encountered some issues with infrastructure dependencies and incomplete CRUD resource lifecycles. However, they solved these using sand-boxed Docker Compose acceptance testing, and by providing developers with the ability to define factory fixtures to be used while fuzzing. An additional problem with expected direct object references was addressed with an endpoint whitelisting system. As a result, they were able to produce the fuzz-lightyear framework.
