Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
5 min read
Published on 05/10/2023
Last updated on 02/05/2024
APIClarity: Using the BFLA Detector
Share
This blog is part of the APIClarity How-To Series.
Using the BFLA Detector
The APIClarity BFLA detector helps detect unauthorized access to functionality in a cloud native application. We introduced the BFLA detector in a previous blog, but for review:
- BFLA is an API security term for Broken Function-Level Authorization
- BFLA issues can lead to security breaches and sensitive data leaks if exploited
- BFLA breaches are on the rise
The BFLA detector has two phases – a learning phase and a detection phase.
During the learning phase, the BFLA detector builds an authorization model based on observed API interactions between services. The user can mark any learned interactions as illegitimate if needed (interactions are assumed to be legitimate during the learning phase).
During the detection phase, the BFLA detector compares API interactions with the model to detect unauthorized access to functionality. Any API calls that are deemed “illegitimate” will be flagged and reported to the user via the UI. Note that BFLA detection is resource intensive, which is why it needs to be explicitly started and stopped.
Let’s try out the APIClarity BFLA detector!
Behind the Scenes
Throughout the APIClarity blog series, we’ve been using Sock Shop as our sample microservice application. See the installation blog for specifics on the setup.
For this blog, Sock Shop is up and running, and I’ve uploaded the OpenAPI specification for the catalogue service (see the upload blog for details on how to do this). I’m generating traffic to Sock Shop using Locust, as described here.
Building the Authorization Model
The first step is to build the authorization model.
From the APIClarity dashboard UI, go to the API Inventory tab on the left (second option, circled in green in Figure 1).
In the API inventory list, select the one for your microservice application. In this case, we’ll select “catalogue.sock-shop” (circled in green in Figure 2).
Next, select the BFLA tab (circled in green in Figure 3).
To start the learning phase of the BFLA detector for the catalogue API, click the START button (Figure 4).
After enough API traffic has been running to build up a model, stop the learning phase (Figure 5).
The UI will then display the authorization model. The top-level is shown in Figure 6.
If you drill down by clicking on the model, you’ll see a list of API endpoints with a shield icon next to each (Figure 7).
The green shield means the API endpoint is considered legitimate:
The red shield means it is considered illegitimate:
Let’s select the “GET /catalogue/{id}” endpoint (Figure 7).
For each API endpoint, you’ll see a list of services that are authorized to use the endpoint. For example, in Figure 8, the Sock Shop “front-end” service is allowed to use the “GET /catalogue/{id}” endpoint. Click on the arrow for details.
Next, you’ll see details about the particular service with API authorization and about the endpoint. Here you can mark an interaction as “illegitimate” if it shouldn’t be allowed.
For our purposes, I’ll mark this API interaction “illegitimate” so we can see APIClarity detect and flag a BFLA violation. I’ve clicked on “Mark as Illegitimate” (Figure 9).
Now when we view the BFLA model, we can see the “GET /catalogue/{id}” endpoint interaction is labelled illegitimate with the red shield (Figure 10).
Detecting BFLA Violations
Now that the authorization model has been built, we can start BFLA detection (circled in green in Figure 11). As mentioned, BFLA detection is not automatically running because it is resource intensive.
We’ll next see a screen indicating that detecting is in progress (Figure 12).
Now when calls are made from the front-end service to the “GET /catalogue/{id}” endpoint, the BFLA detector will flag them for BFLA violations (Figure 13).
Select the API event that was flagged to get details, and then select the BFLA tab (Figure 14).
This will show the BFLA violation in detail (Figure 15).
This screen provides details about which service made the call, the endpoint that was called, and details about why it is considered a violation. Note that it’s possible to mark the interaction as “legitimate” from this screen if it’s actually allowed.
Conclusion
That’s everything you need to know to use the APIClarity BFLA detection capabilities.
Next up in the blog series – how to contribute to the APIClarity project!
Anne McCormick is a cloud architect and open-source advocate in Cisco’s Emerging Technology & Incubation organization.
Subscribe to
the Shift!
Get emerging insights on emerging technology straight to your inbox.
