clock icon

5 min read

Blog thumbnail
Published on 05/10/2023
Last updated on 02/05/2024

APIClarity: Using the BFLA Detector

Share

API_Clarity_How_To_Series
https://www.apiclarity.io/

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). 

API Inventory Dashboard_1
Figure 1: ChooseAPI Inventory Tab from Dashboard UI 

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). 

API_Inventory_Dashboard_Catalogue.Sock-Shop
Figure 2: Select catalogue.sock-shop” from API Inventory 

Next, select the BFLA tab (circled in green in Figure 3). 

API_Inventory_Dashboard_BFLA_Tab
Figure 3: Select the BFLA Tab 

To start the learning phase of the BFLA detector for the catalogue API, click the START button (Figure 4). 

API_Inventory_Dashboard_BFLA_Model_Learning_Phase
Figure 4: Start BFLA Model Learning Phase 

After enough API traffic has been running to build up a model, stop the learning phase (Figure 5). 

API_Inventory_Dashboard_BFLA_Model_Learning_Phase_Stop
Figure 5: Stop BFLA Model Learning Phase 

The UI will then display the authorization model. The top-level is shown in Figure 6

API_Inventory_UI_Authorization_Model_Display_Top_Level 
Figure 6: UI Authorization Model Display Top-Level 

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: 

Icon

The red shield means it is considered illegitimate: 

Icon

Let’s select the “GET /catalogue/{id}” endpoint (Figure 7). 

API_Inventory_Drill Down_on_BFLA
Figure 7: Drill Down on BFLA Model for API Endpoints 

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. 

API_Inventory_List_of_Services_Allowed_API_Endpoint_Access 
Figure 8: List of Services Allowed API Endpoint Access 

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). 

API_Inventory_Mark_API_Interaction_Illegitimate 
Figure 9: Mark API Interaction Illegitimate 

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). 

API_Inventory_API Endpoint is Labelled Illegitimate 
Figure 10: API Endpoint is Labelled Illegitimate 

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. 

API_Inventory_Start BFLA Detection 
Figure 11: Start BFLA Detection 

We’ll next see a screen indicating that detecting is in progress (Figure 12). 

API_Inventory_BFLA_Detection_in_Progress 
Figure 12: BFLA Detection in Progress 

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). 

API_Events_Labelled_as_BFLA_Violation 
Figure 13: API Event Labelled as BFLA Violation 

Select the API event that was flagged to get details, and then select the BFLA tab (Figure 14). 

API_Events_Details 
Figure 14: API Event Details 

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. 

API_Events_BFLA_Violation_Details 
Figure 15: BFLA Violation Details 

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 card background
Subscribe
Subscribe to
the Shift!

Get emerging insights on emerging technology straight to your inbox.

Unlocking Multi-Cloud Security: Panoptica's Graph-Based Approach

Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.

thumbnail
I
Subscribe
Subscribe
 to
The Shift
!
Get
emerging insights
on innovative technology straight to your inbox.

The Shift is Outshift’s exclusive newsletter.

Get the latest news and updates on cloud native modern applications, application security, generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.

Outshift Background