Configuration of BOLA (IDOR) protection¶

Behavioral attacks such as Broken Object Level Authorization (BOLA) exploit the vulnerability of the same name. This vulnerability allows an attacker to access an object by its identifier via an API request and either read or modify its data bypassing an authorization mechanism. This article instructs you on protecting your applications against BOLA attacks.

By default, Wallarm automatically discovers only vulnerabilities of the BOLA type (also known as IDOR) but does not detect its exploitation attempts.

You have the following options to detect and block BOLA attacks with Wallarm:

Manual creation of BOLA trigger
Using the API Discovery module with the automatic BOLA protection - enabled via the Wallarm Console UI

BOLA protection restrictions

Only Wallarm node 4.2 and above supports BOLA attack detection.

Wallarm node 4.2 and above analyzes only the following requests for BOLA attack signs:

Requests sent via the HTTP protocol.
Requests that do not contain signs of other attack types, e.g. requests are not considered to be a BOLA attack if:
- These requests contain signs of input validation attacks.
- These requests match the regular expression specified in the rule Create regexp-based attack indicator.

Requirements¶

To protect resources from BOLA attacks, make sure your environment meets the following requirements:

You have Wallarm node 4.2 or above.
If the filtering node is deployed behind a proxy server or load balancer, configure displaying real clients' IP addresses.

Manual creation of BOLA trigger¶

For the Wallarm node to identify BOLA attacks:

Open Wallarm Console → Triggers and proceed to the BOLA trigger setup.
Set conditions for defining requests as a BOLA attack:
- The number of Requests from the same IP for a certain period of time.
- URI to be protected against BOLA attacks and receiving the specified number of requests. The value should be an API endpoint pointing to an object by its identifier since this endpoint type is potentially vulnerable to BOLA attacks.
  
  To specify the PATH parameter identifying an object, use the symbol *, e.g.:
```
example.com/shops/*/financial_info
```
  URI can be configured via the URI constructor or advanced edit form in the trigger creation window.
- (Optional) Application to be protected against BOLA attacks and receiving the specified number of requests.
  
  If you use the same name for several domains, this filter is recommended to point to the application the domain in the URI filter is assigned for.
- (Optional) One or more IPs originating the requests.
Select trigger reactions:
- Mark as BOLA. Requests exceeding the threshold are marked as a BOLA attack and displayed in the Attacks section of Wallarm Console. Wallarm node does NOT block these malicious requests.
- Denylist IP addresses originating malicious requests and the blocking period.
  
  The Wallarm node will block both legitimate and malicious requests (including BOLA attacks) originating from the denylisted IP.
- Graylist IP addresses originating malicious requests and the blocking period.
  
  The Wallarm node will block requests originating from the graylisted IPs only if requests contain input validation, the vpatch or custom attack signs.
  
  BOLA attacks originating from graylisted IPs
  
  BOLA attacks originating from graylisted IPs are not blocked.
Save the trigger and wait for the Cloud and node synchronization completion (usually it takes 2-4 minutes).

Example of the trigger to detect and block BOLA attacks aimed at shop financial data (the API endpoint is https://example.com/shops/{shop_id}/financial_info):

You can configure several triggers with different filters for BOLA protection.

Automatic BOLA protection for endpoints discovered by API Discovery ¶

Automatic BOLA protection is available if you use the API Discovery module.

To enable auto protection, proceed to Wallarm Console → BOLA protection and turn the switch to the enabled state:

Once BOLA protection is enabled, Wallarm:

Identifies API endpoints that are most likely to be the target of BOLA attacks, e.g. those with variability in path parameters: domain.com/path1/path2/path3/{variative_path4}.

This stage takes a period of time

Identification of vulnerable API endpoints takes a period of time required for deep observation of discovered API inventory and incoming traffic trends.

Only API endpoints explored by the API Discovery module are protected against BOLA attacks in the automated way. Protected endpoints are highlighted with the corresponding icon.
Protects vulnerable API endpoints against BOLA attacks. The default protection logic is the following:
- Requests to a vulnerable endpoint exceeding the 180 requests threshold from the same IP per minute are considered BOLA attacks.
- Only register BOLA attacks in the event list when the threshold of requests from the same IP is reached. Wallarm does not block BOLA attacks. Requests will keep going to your applications.
  
  The corresponding reaction in the autoprotection template is Only register attacks.
Reacts to changes in API by protecting new vulnerable endpoints and disabling protection for removed endpoints.

The BOLA protection section UI enables you to fine-tune the default Wallarm behavior (including BOLA attack blocking) by editing the BOLA autodetection template.

Testing the configuration of BOLA protection¶

Send the number of requests that exceeds the configured threshold to the protected URI. For example, 50 requests with different values of {shop_id} to the endpoint https://example.com/shops/{shop_id}/financial_info:
```
for (( i=0 ; $i<51 ; i++ )) ; do curl https://example.com/shops/$i/financial_info ; done
```
If the trigger reaction is Denylist IP address, open Wallarm Console → IP lists → Denylist and check that the source IP address is blocked.

If the trigger reaction is Graylist IP address, check the section IP lists → Graylist of Wallarm Console.
Open the section Attacks and check that requests are displayed in the list as BOLA attack.

The number of displayed requests corresponds to the number of requests sent after the trigger threshold was exceeded (more details on detecting behavioral attacks). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits (more details on requests sampling).

To search for BOLA attacks, you can use the bola search tag. All filters are described in the instructions on search use.