Skip to content

Manual BOLA 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 describes BOLA protection measures provided by WAAP's triggers.

Other BOLA protection measures

Alternatively or additionally, you can configure Automatic BOLA protection for endpoints found by API Discovery.

Configuring

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

For the Wallarm node to identify BOLA attacks:

  1. Open Wallarm Console → Triggers and proceed to the BOLA trigger setup.

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

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

      BOLA trigger

  4. Save the trigger and wait for the Cloud and node synchronization completion (usually it takes 2-4 minutes).

Testing

  1. 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
    
  2. If the trigger reaction is Denylist IP address, open Wallarm Console → IP listsDenylist and check that the source IP address is blocked.

    If the trigger reaction is Graylist IP address, check the section IP listsGraylist of Wallarm Console.

  3. Open the section Attacks and check that requests are displayed in the list as BOLA attack.

    BOLA attack in the UI

    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.

Trigger processing priorities

When there are several triggers with identical conditions and some of them have nesting level URI, requests to lower nesting level URI will be counted only in the trigger with the filter by the lower nesting level URI.

Trigger's condition

Trigger's condition defines a situation when a trigger should be applied. For example: Brute force, Forced browsing, BOLA. It is selected at the fist step of a new trigger creation.

Triggers without URI filter are considered to be the higher nesting level.

Example:

  • The first trigger with some condition has no filter by the URI (requests to any application or its part are counted by this trigger).

  • The second trigger with the same condition has the filter by the URI example.com/api.

Requests to example.com/api are counted only by the second trigger with the filter by example.com/api.

Requirements and restrictions

Requirements

To protect resources from BOLA attacks, real clients' IP addresses are required. If the filtering node is deployed behind a proxy server or load balancer, configure displaying real clients' IP addresses.

Restrictions

When searching for BOLA attack signs, Wallarm nodes analyze only HTTP requests that do not contain signs of other attack types.