Forced browsing

What is forced browsing?

In a forced browsing attack (also called forceful browsing), an attacker visits URLs containing sensitive information by simply guessing the URL or following a commonly known URL pattern. This attack is made possible by the insecure design of a web application or API.

Forced browsing is formally defined by Mitre in CWE-425. In the latest OWASP Top-10 2021 from the Open Web Application Security Project, forced browsing is not considered a separate cybersecurity category but is included in category A1:2021-Broken Access Control.

Note that forced browsing may seem similar to directory traversal or local file inclusion (LFI) because, in all these cases, a successful attacker can read the content of files on the web server. However, the vulnerabilities that make these attacks possible are very different.

Types of forced browsing vulnerabilities

There are several types of business logic vulnerabilities that make forced browsing possible. They are caused by one or more of the following insecure assumptions during application design or coding:

• Security through obscurity – assuming that if you make an identifier complex enough (in this case, a URL), attackers won’t be able to guess it.
• Common directory names – using common and easily guessed directory names for typical resources, such as /admin/, /config/, or /backup/.
• Lack of authentication – failing to implement, enable, or properly test authentication for all access to URLs or directories that contain sensitive data.
• Lack of access control – using only authentication without also enforcing proper authorization to control access to resources belonging to other users.

Examples of forced browsing attacks

The following are examples of forced browsing attacks made possible by insecure design choices in web applications or APIs.

Forced browsing due to using obscure URLs without authentication

The developer creates or changes a resource URL that is hard to guess and provides access to sensitive information or privileged functionality. For example, the developer might create an administration interface for the web application at the following URL:

https://www.example.com/superadmin/administerthissite.php

The URL is not linked from any website or application and the developer also makes sure it is not indexed or submitted to search engines. The assumption is that if someone needs admin access, they will get the URL. Nobody else will know it, so nobody else can access it and there is no need for authentication.

There are several ways to perform a forced browsing attack:

• Social engineering – tricking a privileged user into exposing the URL
• Brute-force attack or dictionary-based directory enumeration or file enumeration – if the web application has no request throttling, specialized software may be used to automate the attack and send thousands of HTTP requests a second, trying different URLs until a non-error response is received.

This type of vulnerability is common in web applications written by beginners with no security experience, especially for applications meant to be used only within the company Intranet/DMZ. Developers may not bother with authentication since they assume that every user accessing the application has valid access to the internal network and a valid reason to call the URL. Similar issues are also found in APIs, again because developers assume that nobody except a valid caller will know API URLs.

Forced browsing due to insecure direct object references

As an example of a typical insecure direct object reference (IDOR) vulnerability scenario, a web application developer might use simple HTTP authentication for the entire application. Once a user is authenticated, they have permission to gain access to any URL on the site. All user resources are accessible via GET requests with numerical IDs as parameters.

The attacker is a user of the site. After logging in, they are redirected to the following web page that contains their legitimate user information and resources:

https://www.example.com/userdata.php?id=2258

The attacker then enters the following URL into the browser address bar, attempting to use a URL parameter representing another (random) user:

https://www.example.com/userdata.php?id=2259

Since the web application does not use user-level authentication but only simple HTTP authentication, the attacker is able to access sensitive data belonging to any other user. They may even try the following ID:

https://www.example.com/userdata.php?id=1

In many cases, ID=1 may belong to an admin user, with that user’s page containing even more valuable information that will enable the attacker to escalate their attack.

This type of vulnerability is common in simple CMS systems where the developer assumes that all users of the CMS will be company employees, especially if access is additionally restricted, for example, to selected IP addresses.

Forced browsing due to predictable resource location

Forced browsing is closely related to other similar web application security issues, such as directory listing. If a web server has directory listing functionality enabled, forced browsing attacks may allow an attacker to access crucial information by using predictable resource locations in the form of common directory names. Here are some examples:

• https://www.example.com/source-code/
  In this example, the attacker guesses the common directory name source-code, thus getting access to the entire source code structure of the web application.
• https://www.example.com/configuration/
  In this case, the attacker gets access to all the web application configuration files. Some of them may contain sensitive information, such as database access credentials. 
• https://www.example.com/backup/
  This time, the attacker gains access to all the backup files for the web application, which may, for example, include a database dump.

This type of attack is common if the web application administrator uses an older version of a web server because older versions of servers, such as Apache, often have directory listing turned on by default. It is also typical for open-source applications, which often use the same, typical resource locations for storing sensitive content.

Forced browsing due to predictable resource locations is also possible without directory listing if the developer uses common files in common directories. For example:

https://www.example.com/config/config.txt

How to detect forced browsing vulnerabilities?

Forced browsing is not a specific type of vulnerability like SQL injection or cross-site scripting (XSS). An application or API may be vulnerable to forced browsing attacks due to a variety of insecure practices associated with authentication.

Forced browsing vulnerabilities are business logic vulnerabilities and, as such, are difficult to detect using automated tools like vulnerability scanners. Automated scanners such as Invicti and Acunetix by Invicti can actively detect exposed backups, configuration files, and other potentially sensitive resources that are present on the server but not linked or otherwise crawlable. However, automated checks cannot indicate whether a resource has been made accessible on purpose or not. Any such results from automated tools, therefore, require manual review to make sure they correspond to actual vulnerabilities.

How to prevent forced browsing attacks?

To prevent forced browsing attacks, developers should never assume that simple solutions are good enough for application data security:

• Never assume that a publicly accessible URL is impossible to find because it’s not linked or indexed. If it exists, it can be found, so authentication is always a must.
• Never assume that once the user is authenticated, they are a valid user and don’t need any other access control. For every web page and API endpoint that is accessed, developers must ensure that authenticated users also require authorization to access data or resources. Otherwise, they risk introducing an IDOR vulnerability.

Even less experienced developers can usually avoid these basic errors by using common frameworks for web application and API development. Used correctly, these effectively enforce authentication and access control.

Note that any assumption that a web application firewall (WAF) can temporarily mitigate forced browsing attacks is also incorrect. While a WAF may help to block forced browsing for common directories and file names, it is powerless to prevent directory browsing attacks caused by reliance on security through obscurity or a lack of access control.

Frequently asked questions

Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler