2022 Ultimate Security Guide for Small Businesses. Read Now

Forced Browsing – Detection and Prevention

What is Forced Browsing?

Forced browsing is an attack where the goal is to list and access resources that are not referenced by the application but are still accessible, thereby affecting the confidentiality of that data. This can be done by manipulating the URL or parameters in a request, or by trying to access a file or directory directly instead of through the proper channels.

Forced browsing is a common attack vector, and can be used to gain access to sensitive data, bypass security controls, or perform other malicious actions.

This attack has many names and is also called: direct request attack, forceful browsing, predictable resource location, file enumeration, directory enumeration, resource enumeration, and resource location. It is formally defined by Mitre in CWE-425. In the latest OWASP Top-10 2021, forced browsing in included in the “A1:2021-Broken Access Control” category.

One example of forced browsing is an attacker trying to access a file directly, instead of through the application’s interface. For example, if an application has a page that displays a user’s profile information, the attacker may try to access the file that stores the user’s profile information directly.

If the file is not properly protected, the attacker can view the contents of the file, which may include sensitive information such as the user’s name, address, and contact information.

Another example of forced browsing is an attacker manipulating the URL or parameters in a request in order to access a resource that they are not authorized to view. For example, an attacker may try to access a page that requires a login by manipulating the URL so that they are bypass the login page.

If the application does not properly validate the URL or parameters, the attacker can gain access to the resource.

Forced browsing vulnerabilities happen when a web application doesn’t use the right authorization or access controls on all restricted URLs, scripts, and/or files.

Most of the time, these security vulnerabilities happen when the wrong assumption is made that restricted resources can only be reached through a certain navigation path, so only certain points on the path perform authorization checks.

Forced browsing vulnerabilities happen when a web application doesn’t use the right authorization or access controls on all restricted URLs, scripts, and/or files.

Most of the time, these security vulnerabilities happen when the wrong assumption is made that restricted resources can only be reached through a certain navigation path, so only certain points on the path perform authorization checks.

This diagram illustrates forced browsing. The attacker authenticates and then browses to the restricted URL directly (which the application allows). Thereby, the attacker is able to steal the confidential data.
This diagram illustrates forced browsing. The attacker authenticates and then browses to the restricted URL directly (which the application allows). Thereby, the attacker is able to steal the confidential data.

Forced Browsing Examples

Example 1:

Application App1 was designed with the intent that users can view their own profile but not that of other users. This data is fetched via GET requests and urls for those users appears as follows:

www.app1.com/userinfo.php?id=0001

A malicious user discovers that they can see confidential information of other users by modifying the id parameter in the URL to that of other users such as:

www.app1.com/userinfo.php?id=0002

Example 2:

Administrators of App2 can upload confidential documents. These resources are not meant to be accessed by unauthorized individuals.

An unauthenticated attacker discovers that they can obtain access to these files by browsing directly to links such as:

www.app2.com/files.php?file=highlyconfidential.pdf

Forced Browsing Testing Methods

Hackers can perform forced browsing or otherwise access unlinked resources using techniques such as number rotation or by simply guessing the URL if it is generated in a predictable way. Attackers can also use automated tools that search for indirectly linked resources that may contain sensitive information.

Scanners automate this process by searching for indirectly linked yet common valuable resources. For example, the Nikto scanner is configured to search through the existing files and directories in the application for common routes such as “/password/, “/admin/”, and “/test/”.

Manual testing for forced browsing includes attempting to access resources that are not normally accessed or that should not be accessed without going through certain controls such as authentication first. Unlike automated testing, manual testing is not limited to common resources and routes.

Manual testing can be done by enumerating and making a list of resources that should be restricted and then trying to browse them forcefully.

At BB-SEC, penetration testing includes both manual and automated forced browsing tests, combining the best of both worlds. Thorough manual testing is done to detect easy-to-miss but high-impact forced browsing vulnerabilities. It is supplemented with automated techniques for wide-scope coverage so that customers get the best value for their dollar.

Forced Browsing Prevention

Forced browsing typically occurs when developers make false assumptions such as:

  •  “A publicly accessible URL is impossible to find just because it is not linked directly from the site.” The truth is that URLs can and do get found. Sometime’s it’s easy easy as the links even showing up in Google search results. Authentication and authorization controls are a must to prevent this.
  • “An authenticated user will not try to access resources they should not” Authenticated user can and sometimes do attempt to access resources they should not such as those that should be restricted to other individual accounts of the same privilege level or even those that are intended for administrator access only. Access controls should be properly implemented for all resources.

In other words, forced browsing can be prevented with strong authentication and authorization controls:

  • All resources or pages that exist that should not be accessible by anonymous users should require the proper session tokens or cookies to be accessible. It must be made sure for those pages that only authenticated users are authorized to gain access to the restricted resources.
  • Horizontal and Vertical authorization checks and controls are implemented at every step to ensure security.

Another control that is occasionally but more rarely used is creaton of a white list for whom can explicitly access restricted resurces. Any request not in this allowlist is denied by default.

Penetration testing and vulnerability scans such as those offered by BB-SEC should be performed to detect vulnerabilities such as forced browsing. While scans are efficient to cover significant scope, they fail to uncover most cases of forced browsing vulnerabilities and especially those that have unusually named URL paths.

As such penetration testing is recommended for discovering this vulnerability.

Feel free to read our other contents: Path Traversal (Directory Traversal) – Definition and Prevention

Forced Browsing

About BB-SEC

We are a North Carolina-based cyber security consulting firm, specializing in premium quality services such as penetration testing, code reviews, and architecture reviews. Find out more about our most in-demand services:

Popular Post Categories

More Posts

BB-SEC

BB-SEC – New Brand Name

We have rebranded. Black Belt Security is now using the much shorter and quicker-to-type BB-SEC name as the brand name for our

Reflected Cross-Site Scripting (Reflected XSS)

Reflected XSS Cross-Site Scripting

What is Reflected Cross-Site Scripting (XSS)? Reflected Cross-Site Scripting vulnerabilities are a subcategory of XSS vulnerabilities. Reflected XSS attacks occur when an

Share this Post

Browse More Posts