Skip to content

Protection Against Forced Browsing

Forced browsing attack is one of the attack types that is not detected by Wallarm out-of-the-box, its detection should be properly configured as this guide describes.

Forced browsing attacks are characterized by a large number of response codes 404 returned to requests to different URIs for a limited timeframe.

The aim of this attack is to enumerate and access hidden resources (e.g. directories and files containing information on application components). The forced browsing attack type usually allows attackers to collect the information about application and then perform other attack types by exploiting this information.

Note that besides protection from forced browsing, in a similar way, you can configure protection against brute-force attacks.

Configuring

To configure protection against forced browsing:

  1. Open Wallarm Console → Triggers and open the window for trigger creation.

  2. Select the Forced browsing condition.

  3. Set the threshold for the number of the 404 response codes returned to the requests having the same origin IP requests.

  4. If required, specify URI to activate the trigger only for requests sent to certain endpoints, for example:

    • Specify the URI of the resource file directory.
    • If using nested URIs, consider trigger processing priorities.
    • If the URI is not specified, the trigger will be activated at any endpoint with the request number exceeding the threshold.

    URI can be configured via the URI constructor or advanced edit form in the trigger creation window.

  5. If required, set other trigger filters:

    • Application the requests are addressed to.
    • One or more IP the requests are sent from.
  6. Select trigger reactions:

    • Mark as forced browsing. Requests received after the threshold exceeding will be marked as the forced browsing attack and displayed in the Attacks section of Wallarm Console.
    • Denylist IP address and the period for IP address blocking to add IP addresses of malicious request sources to the denylist. The Wallarm node will block all requests originated from the denylisted IP after the threshold was exceeded.
    • Graylist IP address and the period to graylist IP addresses of malicious request sources. The Wallarm node will block requests originated from the graylisted IPs only if requests contain input validation, the vpatch or custom attack signs. Brute‑force attacks originated from graylisted IPs are not blocked.

    Forced browsing trigger example

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

You can configure several triggers for brute force protection.

Testing

  1. Send the number of requests that exceeds the configured threshold to the protected URI. For example, 31 requests to https://example.com/config.json (matches https://example.com/**.**):

    for (( i=0 ; $i<32 ; i++ )) ; do curl https://example.com/config.json ; done
    
  2. If the trigger reaction is Denylist IP address, open Wallarm Console → IP listsDenylist and check that 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 a forced browsing attack.

    Forced browsing attack in the interface

    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 the forced browsing attacks, you can use the dirbust filter. 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 forced browsing 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 forced browsing attack signs, Wallarm nodes analyze only HTTP requests that do not contain signs of other attack types.