A false negative BOLA case on crAPI

[ceylanb]

The /identity/api/v2/vehicle/{vehicleId}/location endpoint is vulnerable to BOLA attacks as stated in Challenge 1. To test whether EvoMaster can find the vulnerability, I've run it (v4.0.0) on crAPI for 5 minutes. As a result, it could write a test that generates a valid request for the vulnerable endpoint with a valid vehicleId:

    # Calls:
    # (200) GET:/identity/api/v2/vehicle/{vehicleId}/location
    @timeout_decorator.timeout(60)
    def test_33_get_on_location_returns_object(self):
        
        token_user1 = "Bearer "
        headers = {}
        headers["content-type"] = "application/json"
        body = " { " + \
            " \"email\": \"user3@bozogullarindan.com\", " + \
            " \"password\": \"Password3!\" " + \
            " } "
        res_user1 = requests \
                .post(self.baseUrlOfSut + "/identity/api/auth/login", 
                    headers=headers, data=body, allow_redirects=False)
        token_user1 = token_user1 + res_user1.json()["token"]
        
        
        headers = {}
        headers["Authorization"] = token_user1 # user1
        headers['Accept'] = "application/json"
        res_0 = requests \
                .get(self.baseUrlOfSut + "/identity/api/v2/vehicle/cd515c12-0fc1-48ae-8b61-9230b70a845b/location",
                    headers=headers, timeout=60)
        
        assert res_0.status_code == 200
        assert "application/json" in res_0.headers["content-type"]
        assert res_0.json()["carId"] == "cd515c12-0fc1-48ae-8b61-9230b70a845b"
        assert res_0.json()["vehicleLocation"]["latitude"] == "31.284788"
        assert res_0.json()["vehicleLocation"]["longitude"] == "-92.471176"
        assert res_0.json()["fullName"] == "Pogba"
        assert res_0.json()["email"] == "pogba006@example.com"

EvoMaster has passed the challenge by finding the exposed valid vehicle ID in the /community/api/v2/community/posts/{postId} endpoint, and it could access the vehicle ID (cd515c12-0fc1-48ae-8b61-9230b70a845b) of another user (Pobga). However, as seen in the following image, it couldn't raise the fault code (206) related to missed authorization checks, BOLA.

This is a false negative case, and the algorithm can be improved to resolve this problem.

[arcuri82]

hi @ceylanb ,

thanks for reporting this. I love this kind of discussions! ;)
If you want to see how these checks work in EvoMaster in details, you can read: https://github.com/WebFuzzing/EvoMaster/blob/master/docs/publications/2025_issre.pdf

The problem here is that how do you know that user1 has no right to access that information of Pobga? maybe user1 is an administrator. even if not, how can you tell that such information created by user Pobga is not public?

For example, a user ceyland could make a POST to create an issue on a repository of GitHub APIs, and other users of API, like arcuri82, might do a GET to read such issue report.

Right now, EvoMaster is very conservative, and only flags BOLA that have high chances to be real and not false positive (see that research paper for the exact algorithm used).

An alternative would be to provide formalized access policy rules as part of the input to the fuzzer, and use those as extra oracles. But I am aware of no such standard to define such policies for REST APIs. Do you know of any?

We could create our own standard supported by EvoMaster, but that most likely will not happen this year (too much to do already)