Failure to Restrict URL Access

Background on the OWASP Top 10 and Failure to Restrict URL Access

Failure to Restrict URL Access is one of the common vulnerabilities listed on the Open Web Application Security Project’s (OWASP) Top 10. The OWASP Top 10 details the most critical vulnerabilities in web applications. The goal of the OWASP Top 10 is to increase awareness among developers so that application security measures are built into the development process.

What Is “Failure to Restrict URL Access?”

If your application fails to appropriately restrict URL access, security can be compromised through a technique called forced browsing. Forced browsing can be a very serious problem if an attacker tries to gather sensitive data through a web browser by requesting specific pages, or data files.

Using this technique, an attacker can bypass website security by accessing files directly instead of following links. This enables the attacker to access data source files directly instead of using the web application. The attacker can then guess the names of backup files that contain sensitive information, locate and read source code, or other information left on the server, and bypass the "order" of web pages.

Simply put, Failure to Restrict URL Access occurs when an error in access-control settings results in users being able to access pages that are meant to be restricted or hidden. This presents a security concern as these pages frequently are less protected than pages that are meant for public access, and unauthorized users are able to reach the pages anonymously. In many cases, the only protection used for hidden or restricted pages is not linking to the pages or not publicly showing links to them.

How Can Attackers Exploit Failure to Restrict URL Access Vulnerabilities?

Attackers can use fairly simple methods to access and interact with hidden/unlinked pages on a site, the most common being a type of attack called “forced browsing.” Forced browsing attacks can take place when an attacker is able to correctly guess the URL of or use brute force to access an unprotected page. This process is much easier on the attacker if a flaw exists in the page’s access-control policy. These flaws typically include hidden pages with guessable URLs, applications that permit access to pages that are meant to be hidden/restricted, outdated access-control policy code, and a lack of server-side access-control policy.

How to Prevent Breaches Due to Failure to Restrict URL Access

To prevent forced browsing, you can use appropriate permissions or ACLs to disallow anonymous reading. Also, do not allow anonymous web visitors user read permissions to any sensitive data files.

Secondly, define the list of file types available for remote reading on the server. Many servers allow you to define which file extensions can be served remotely. For example, .log, .dat and database files are not files that all users should have access to - except through secure channels.

Also, remove all unnecessary files from web-accessible directories. That is, if files are unneeded within the directory, remove them, even though they may be secure. ACLs may need to change in the future, and this could pose a security risk.

Finally, use virtual directories for web access, separate secure directories data. They allow you to specify granular ACLs and can help in directory traversal bugs.

Protecting Web Applications From Forced Browsing

For a website to be safe from "Forced Browsing"/"Failure to Restrict URL Access" attacks, it is imperative that access-control settings are accurate and up to date for every page and application on the site. There are automated tools for this process, but they are typically less than perfectly accurate, which will result in site vulnerabilities. The best approach for ensuring that a site is protected is to use code analysis in conjunction with security testing across the site. It is through this process that developers and security testers can make sure that their access-control policy is effective and extends to every site page. Finally, it is important that testing occurs prior to launch in order to preemptively verify that pages are protected.