What Is Forced Browsing

Forced browsing, also called forceful browsing, is an attack technique against badly protected websites and web applications, which allows the attacker to access resources that they should not be able to access. Such resources may contain sensitive information. Forced browsing is a common web application security issue caused by careless coding.

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

Here are some examples of forced browsing attacks.

Using Hard to Guess URLs

The developer of the website or web application creates a difficult to guess URL for a valuable resource using unconventional file names and directory names. This URL enables access to privileged functions with no authentication. For example:

https://www.example.com/administration/administersite.php

The developer assumes that the URL is too complex to guess, it is not linked to, it is not indexed or submitted to Google, and therefore nobody will certainly find it. However, the attacker discovers this URL (for example, using social engineering or other techniques and scanning tools such as brute-force directory enumeration, file enumeration, resource enumeration, etc.), accesses it, and attains administrator access. Despite what many developers think, identifying resources is not that difficult at all for a skilled attacker.

Predictable Resource Location

The developer of a website or web application uses simple authentication. Once a user is authenticated, they can access any URL of the site.

The attacker is a user of the site. They first access the following web page:

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

Then, they enter the following URL into the browser address bar, attempting to use a URL parameter representing another user:

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

If authentication is too simple, they are able to attain access to sensitive data belonging to any other user. They may also try the following ID:

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

In many cases, ID=1 may belong to an admin user and the page may contain valuable information that will enable the attacker to escalate their attack.

Accessing Common Files and Directories

Forced browsing is closely related to other similar web application security issues such as insecure direct object references and directory listing. For example, if a web server has directory listing turned on, forced browsing may enable the attacker to access crucial information. Here are some examples:

• https://www.example.com/source-code/In this example, the web server has directory listing turned on and the attacker guesses a 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 those files may contain sensitive information such as access passwords for databases.
• 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.

How to Avoid Forced Browsing

To avoid forced browsing attacks, the developer must never assume that simple solutions are enough for application data security:

• The developer must never assume that a publicly accessible URL is impossible to find. If it exists, it can be found. Authentication is a must.
• The developer must never assume that once the user is authenticated, they don’t need any other access control. For every web page that is accessed, the developer must make sure that the authenticated user is authorized to access the content.

To discover potential vulnerabilities, you should employ efficient, automated web application vulnerability scanning using a tool such as Acunetix. This will help you find most problems very quickly and eliminate them before an attacker can exploit them. You should also follow up with manual penetration testing to find issues difficult to discover automatically, such as forced browsing.

THE AUTHOR

Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
LinkedIn

Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.