In this VMblog expert Q&A, we spoke with Scott Gerlach, co-founder and Chief Security Officer (CSO) of StackHawk. Today, we dive into the world of application security vulnerabilities, specifically exploring the concept of BOLA vulnerabilities, and shedding light on Software Composition Analysis (SCA) and Static Application Security Testing (SAST). With Scott's extensive experience in the field, we aim to understand the intricacies of these things and gain new insights and discover new perspectives from an industry-leading expert.

VMblog:  What are the shortcomings of SCA and SAST?

Scott Gerlach:  Software composition analysis (SCA) and static application security testing (SAST) offer multiple benefits, but there are a few drawbacks that come with them that make these approaches less appealing, including insecure direct object references (IDOR), broken function level authorization and broken object level authorization (BOLA). The latter of these is particularly dangerous when it comes to APIs, as it introduces opportunities to wreak significant havoc, like remote car function takeovers using just the VIN number.

VMblog:  What is BOLA?

Gerlach:  BOLA is kind of a hard thing to understand, but a simple way to think about it is, can customer A access the assets of customer B. In the software development world, this is also known as tenancy filtering.

VMblog:  What are the potential risks associated with a BOLA vulnerability?

Gerlach:  Malicious actors exploit a BOLA vulnerability by manipulating object identifiers, parameters, or references associated with objects. If they're successful, they can gain access to sensitive user data, modify or delete critical resources, impersonate other users, and make all sorts of unauthorized actions.

VMblog:  Are there any real-world examples of this?

Gerlach:  There was a large-scale BOLA discovery earlier this year in remote car access APIs. Web Application Security Researcher, Sam Curry and his team found a lot of problems with those APIs including account takeover, null character, filtering issues, and a ton of back-end systems that were accessible.

A particularly severe issue they found was that they could gain access to a user's account and take control of their vehicle by only knowing the VIN number-a piece of information that is fairly public and accessible.

VMblog:  How do APIs become vulnerable to BOLA? Where can this start showing up in the API code?

Gerlach:  While SAST can identify areas in the code with the potential for SQL injections, it cannot identify or verify the connection between the user and the data. The lack of ability to identify and verify connections opens the door for BOLAs to creep into the code.

VMblog:  What can developers do if they find a BOLA in an API's code?

Gerlach:  Go beyond just resolving it: add testing to make sure it doesn't get reintroduced into the API in the future. This is better achieved with the security team and the developer team working together in tandem.

VMblog:  How can solutions like dynamic application security testing (DAST) help prevent BOLA issues from emerging?

Gerlach:  DAST can test dynamically, as its name suggests, enabling developers to be more fluid and flexible with their testing strategies. This can help development teams continually identify potential BOLA risks

VMblog:  What resources or references do you recommend for learning more about BOLA?

Gerlach:  The OWASP API Top 10, OWASP Web Security Testing Cheat Sheet, SANS Institute, SheHacksPurple, and security-focused conferences like BlackHat.

VMblog:  What does the future of API and application security testing look like?

Gerlach:  The future is flexible. Developers need to be able to address security concerns as they arise, regardless of where in the development cycle they are. Flexibility helps a great deal here, so they can be more agile in responding to issues and help resolve them in a timely manner.

##